On 5/29/07, Ludovic Dubost <ludovic@xwiki.com> wrote:

Hi,

Concerning the XWiki model and the JCR model, this is a really
interesting and important discussion..
There are quite a few benefits to have our objects comply with the JCR
model. I've thought a few times about and XWiki model on top of JCR, and
this not only for storage.
I don't think we should view right away JCR as "storage".. We can
definitively view it as an API also..

The main question we should ask ourselves is:

1/ Can we maintain the old XWiki api to have a layer of compatibility on
top of an XWiki model being a superset of the JCR model.
2/ Can we support a different storage mecanism using the JCR model than
the JCR storage API
3/ Can we extend the JCR model with an XWiki model
4/ Do we like the JCR model (is it a api that is nice to use)
5/ How would the XWiki scripting api (new version, not compatible) look
like using the JCR model

Concerning the mapping of XWiki<->JCR. I'm not sure that Farm is JCR
engine..
In the current usage of the Farm, we have different DBs for different
wikis in a farm.. Are we sure we can get this behavior from
engine/repository

Farm <=> JCR engine
Wiki <=> Repository
Space <=> Node

Ludovic

Vincent Massol a écrit :
> Hi everyone,
>
> On May 29, 2007, at 5:43 PM, Stéphane Laurière wrote:
>
>> Hi Vincent, Sergiu and all,
>>
>> Some remarks below after having discussed today with Mikhail Kotelnikov
>> (in CC, author of WikiModel, co-founder of Cognium Systems, a partner of
>> Nepomuk that XWiki company is part of [3]).
>>
>> [1]
>> http://nepomuk.semanticdesktop.org/xwiki/bin/view/Components/WikiModel
>> * WikiModel v2 contains an alpha version of a JavaCC grammar for the
>> XWiki syntax. WikiModelv2 is common event model working currently with
>> several wiki syntaxes: creole, gwiki, jspwiki, mediawiki, xwiki.
>>
>> [2] WikiModel v2 source code download:
>> http://nepomuk.semanticdesktop.org/xwiki/bin/download/Components/WikiModel/WikiModelV2.zip
>>
>>
>> [3] http://nepomuk.semanticdesktop.org
>>
>> [4] http://www.cogniumsystems.com
>>
>> The topic is not easy, we are aware several strategies are possible,
>> here's a contribution :-)
>>
>> Sergiu Dumitriu wrote:
>>> On 5/28/07, Vincent Massol <vincent@massol.net> wrote:
>>>> Hi,
>>>> Starting from today I'm going to spend some time every week on the
>>>> V2 Architecture/Redesign. Today I'd like to start at the heart of
>>>> the topic with the domain model. Here's my proposal:
>>>> * Model classes are classes representing the XWiki model. The main
>>>> classes are: - Farm - Wiki - Space - Document - XObject - XClass
>>> Attachment
>>
>>
>> Couldn't we try to merge the Document, XObject and Attachment classes
>> into a single class, along the lines of the JCR API where there is
>> mainly a Node class that can have various types and various properties?
>> An Attachment would be represented by a Node with a property containing
>> a binary stream and possibly other properties such as the text
>> description, the title etc. The advantage of this approach is to
>> offer a simplified and more flexible model.
>
> [snip]
>
> That's an interesting idea. However for me the relationship with JCR
> is not an advantage and certainly not a requirement. We want our model
> classes to be independent on any storage mechanism. However from a
> design perspective it's interesting to evaluate how the model classes
> could look like if they were using a Node API similar in design to the
> JCR (which I don't know so well but I guess it's similar to the DOM
> API too).
>
> I can see some pros and cons:
>
> Pros:
> - flexibility in that it's easy to add a new node type
> - genericity in that it's a hierarchical structure (a graph) and it
> would support nested nodes
>
> Cons:
> - less strongly typed API in general a more generic API vs a more
> business oriented API with the API I proposed. Compare
> Space.getDocuments () to node.getElementsByType(NodeType.DOCUMENT). Of
> course I guess we could add a SpaceNode class that implements the Node
> interface and that method could then have a getDocuments() API which
> internally would be implemented as
> getElementsByType(NodeType.DOCUMENT). There's still the problem of
> doing "if"s on the node type to cast to the correct specific node
> class. Personally I've always found the DOM API to be a real pain
> (which is probably why there are frameworks like JDOM, DOM4J, etc).
> - There are business APIs to implement too (not just navigating) and
> these APIs don't make much sense applied to a Node. They do make sense
> applied to business objects.
>
> We need to discuss this more and I need to think more about this too
> to evaluate the consequences.
>
> Thanks for this interesting discussion Stephane
> -Vincent
>
>
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
> For general help: mailto: sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>

--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic

--
You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto: sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws