[ArchitectureV2] Model proposal

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ArchitectureV2] Model proposal

vmassol
Administrator
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
   - (probably lots of others)
* As you can see I'd like to introduce the Space and Farm objects
* We create a model/ build module in trunks-devs/xwiki/model for  
storing model classes
* Model classes cannot access other classes outside of the model/  
module. They are meant to be used by components to provide services  
but they shouldn't provide services themselves. They can methods to  
manipulate their fields and they can call each other but they cannot  
call outside of their model.
* We use the org.xwiki.model package for storing Model classes
* These model classes are all user public (API)

WDYT?

Barring any negative feedback I'll start implementing this today and  
in the coming days. One question that remains unanswered in my mind  
is how do we integrate back these model classes into the V1  
architecture. I think we should be able to retrofit the existing  
classes to use these classes by composition. For example the Document  
object could have 2 fields: one org.xwiki.model.Document and one  
org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and  
Farm, etc. I'm not sure how this would work out though. Any idea is  
welcome.

Thanks
-Vincent





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Sergiu Dumitriu
On 5/28/07, Vincent Massol <[hidden email]> 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
XPropertyMeta
XPropertyDefintion
XProperty

>    - (probably lots of others)
> * As you can see I'd like to introduce the Space and Farm objects
> * We create a model/ build module in trunks-devs/xwiki/model for
> storing model classes
> * Model classes cannot access other classes outside of the model/
> module. They are meant to be used by components to provide services
> but they shouldn't provide services themselves. They can methods to
> manipulate their fields and they can call each other but they cannot
> call outside of their model.
> * We use the org.xwiki.model package for storing Model classes
> * These model classes are all user public (API)
>
> WDYT?
Agree

>
> Barring any negative feedback I'll start implementing this today and
> in the coming days. One question that remains unanswered in my mind
> is how do we integrate back these model classes into the V1
> architecture. I think we should be able to retrofit the existing
> classes to use these classes by composition. For example the Document
> object could have 2 fields: one org.xwiki.model.Document and one
> org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and
> Farm, etc. I'm not sure how this would work out though. Any idea is
> welcome.
>
> Thanks
> -Vincent
Agree for XWiki, but I don't know why should we have a Space object in
the old Document. Are there any Space methods in the current code?

You have my support. As much as my time allows, I'll help you on this.

Sergiu
--
http://purl.org/net/sergiu



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Stéphane Laurière-6
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 <[hidden email]> 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.

> XPropertyMeta

What would XPropertyMeta stand for?

With Mikhail we tried to produce a wiki model that can be easily mapped
to the JCR model, and we came up with the following core elements:

- Node (Document, XObject, Attachment would then be represented using
Node instances)
- NodeType (JCR terminology, equivalent to XClass)

- ID: our proposal would be to create a top level class for IDs so that
(i) can have several URIs for the same ID, (2) all manipulations with
IDs (renaming: giving a new URI for an ID) are distinct from Node
manipulation, (iii) this will allow the implementation of a service
dealing only with IDs and URIs separately from the Node implementation.

- Session: similar to the XWikiContext and to the JCR Session class:
it's the user's context, giving access to all repository services
adapted to that context.

In addition to these core elements, we should add to the model a Version
class, but its scope remains to be discussed.

Just to see where we are on the map, we also drew the comparison below
between the XWiki2 and JCR models:
Farm <=> JCR engine
Wiki <=> Repository
Space <=> Node
Document <=> Node
Attachment <=> Node
XClass <=> NodeType
XPropertyDefinition <=> PropertyDefinition
XProperty <=> Property
XObject <=> Node

 From the discussion we had, it appears that at least Cognium Systems
would be interested in designing core wiki libraries that could be then
used by their collaborative engine in addition to being used by XWiki.
Obviously, other companies and researchers are likely to take part in
the design of such libraries, given the importance of wikis. We believe
that such libraries would have more impact if they are maintained by a
wide community of companies and researchers, avoiding the situation
where a given community fears to use some library because it has too
tight links with a single company. This has to be assessed, though. What
do you think?

Within Nepomuk, we're currently designing such core wiki libraries. We
will upload a Node API proposal this week, and we plan to implement it
on top of Jackrabbit by mid-june. The more we can share efforts toward a
sound and flexible implementation of the core services, the better, but
obviously the XWiki2 strategy regarding the Nepomuk effort remains to be
investigated and discussed.



Stéphane and Mikhail



> XPropertyDefintion XProperty
>
>> - (probably lots of others) * As you can see I'd like to introduce
>> the Space and Farm objects * We create a model/ build module in
>> trunks-devs/xwiki/model for storing model classes * Model classes
>> cannot access other classes outside of the model/ module. They are
>> meant to be used by components to provide services but they
>> shouldn't provide services themselves. They can methods to
>> manipulate their fields and they can call each other but they
>> cannot call outside of their model. * We use the org.xwiki.model
>> package for storing Model classes * These model classes are all
>> user public (API)
>>
>> WDYT?
>
> Agree
>
>>
>> Barring any negative feedback I'll start implementing this today
>> and in the coming days. One question that remains unanswered in my
>> mind is how do we integrate back these model classes into the V1
>> architecture. I think we should be able to retrofit the existing
>> classes to use these classes by composition. For example the
>> Document object could have 2 fields: one org.xwiki.model.Document
>> and one org.xwiki.model.Space. The XWiki object could have 2
>> fields: Wiki and Farm, etc. I'm not sure how this would work out
>> though. Any idea is welcome.
>>
>> Thanks -Vincent
>
> Agree for XWiki, but I don't know why should we have a Space object
> in the old Document. Are there any Space methods in the current code?
>
>
>
> You have my support. As much as my time allows, I'll help you on
> this.
>
> Sergiu
>

--
Stéphane Laurière
[hidden email]

XWiki Research
http://www.xwiki.com
http://concerto.xwiki.com
http://nepomuk.semanticdesktop.org




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

vmassol
Administrator
In reply to this post by vmassol
Some more details on this topic:

* We should have a consistent naming. Either we use XObjects/XClass  
and then we have to use X in front of everything: XFarm, XWiki  
(funny), XSpace, XDocument, etc or we agree that the namespace is  
enough (org.xwiki.model) to indicate that these are all XWiki classes  
and we drop the X. This is my preference. When we write documentation  
we can refer to XObjects/XClass/ to separate them from Java Objects/
Class though.

* Here's a cardinality and dependency graph of main model classes:

(Farm) 1 --> * (Wiki) 1 --> * (Space) 1 --> * (Document) 1 --> *  
(Object) 1 --> * (Property)

* I want to come back on something I said in the email below. I said  
the Model classes shouldn't depend on any other component. I don't  
think this is true anymore. The reason is that I think we need to  
model the cardinality defined above in the model classes. For example:

Farm:
- addWiki(Wiki wiki)
- removeWiki(String wikiName)
- List getWikis()
- Wiki getWiki(String wikiName)

Wiki:
- addSpace(Space space)
- removeSpace(String spaceName)
- List getSpaces()
- Space getSpace(String spaceName)
- Farm getFarm()

Space:
- addDocument(Document document)
- removeDocument(String documentName)
- List getDocuments()
- Document getDocument(String documentName)
- Wiki getWiki()

The same applies to Document and Object.

Now the interesting part is what happens for example when  
Space.getDocuments() is called? The user will expect that it returns  
the lists of documents in the space. This requires access to the  
storage component. Thus I now believe we should have the model  
classes have the storage component injected. The alternative is  
either to not have the above-defined methods in the model classes  
(which I think would be a pity) or have some external services to  
load the data in the model objects. But that's tricky because it  
would mean loading the whole object graph at once or doing some  
tricky transparent lazy loading. Thus my preference goes to adding a  
dependency to the storage component in the model classes.

* Now we'll want to cache data instead of hitting the database every  
time. We could do this in several ways: using the database cache,  
using a delegating caching storage implementation or doing the  
caching in the model classes themselves using a caching service. I'm  
not sure here but a delegation at the level of the storage component  
sounds nicer to me at first glance.

WDYT?

Thanks
-Vincent

On May 28, 2007, at 9:38 AM, Vincent Massol 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
>   - (probably lots of others)
> * As you can see I'd like to introduce the Space and Farm objects
> * We create a model/ build module in trunks-devs/xwiki/model for  
> storing model classes
> * Model classes cannot access other classes outside of the model/  
> module. They are meant to be used by components to provide services  
> but they shouldn't provide services themselves. They can methods to  
> manipulate their fields and they can call each other but they  
> cannot call outside of their model.
> * We use the org.xwiki.model package for storing Model classes
> * These model classes are all user public (API)
>
> WDYT?
>
> Barring any negative feedback I'll start implementing this today  
> and in the coming days. One question that remains unanswered in my  
> mind is how do we integrate back these model classes into the V1  
> architecture. I think we should be able to retrofit the existing  
> classes to use these classes by composition. For example the  
> Document object could have 2 fields: one org.xwiki.model.Document  
> and one org.xwiki.model.Space. The XWiki object could have 2  
> fields: Wiki and Farm, etc. I'm not sure how this would work out  
> though. Any idea is welcome.
>
> Thanks
> -Vincent
>
>



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

vmassol
Administrator
In reply to this post by Stéphane Laurière-6
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 <[hidden email]> 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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Ludovic Dubost
In reply to this post by Sergiu Dumitriu

I'll answer in a separate mail the discussion about JCR..

Sergiu Dumitriu a écrit :

> On 5/28/07, Vincent Massol <[hidden email]> 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
I prefer MultiWiki

>>    - Wiki
>>    - Space
>>    - Document
>>    - XObject
I agree with Stephane that we should look to merge Document, XObject
into XObject, Document should be a superset of XObject.
Attachment I think should not be a superset of XObject put a superset of
XProperty

   - XClass
>
> Attachment
> XPropertyMeta
> XPropertyDefintion
I don't understand the difference between XPropertyMeta and
XPropertyDefinition
I would prefer XMetaProperty or XClassProperty or XPropertyClass (we are
using PropertyClass currently)

There is also XMetaClass to define the class.

> XProperty
>
Ludovic
I

--
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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Ludovic Dubost
In reply to this post by vmassol


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 <[hidden email]> 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 [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Re: [ArchitectureV2] Model proposal

Sergiu Dumitriu
In reply to this post by vmassol
On 5/29/07, Vincent Massol <[hidden email]> wrote:

> Some more details on this topic:
>
> * We should have a consistent naming. Either we use XObjects/XClass
> and then we have to use X in front of everything: XFarm, XWiki
> (funny), XSpace, XDocument, etc or we agree that the namespace is
> enough (org.xwiki.model) to indicate that these are all XWiki classes
> and we drop the X. This is my preference. When we write documentation
> we can refer to XObjects/XClass/ to separate them from Java Objects/
> Class though.
>
I'm for the second option, with the minor objection that I don't like
having an Object class. Name collision with the most used class in the
Java world. But I can deal with this inconvenience.

> * Here's a cardinality and dependency graph of main model classes:
>
> (Farm) 1 --> * (Wiki) 1 --> * (Space) 1 --> * (Document) 1 --> *
> (Object) 1 --> * (Property)
>

There's also:
(Document) 1 --> 0..1 (Class) 1 --> * (PropertyDefinition) 1 --> 1
(PropertyMeta) 1 --> * (PropertyDefinition) 1 --> * (primitives
[string, int])

This is the current model, and it might need adjustments. For example,
the PropertyMeta can only be defined in the Java world in this model,
and we'd like to change this.

> * I want to come back on something I said in the email below. I said
> the Model classes shouldn't depend on any other component. I don't
> think this is true anymore. The reason is that I think we need to
> model the cardinality defined above in the model classes. For example:
>
> Farm:
> - addWiki(Wiki wiki)
> - removeWiki(String wikiName)
> - List getWikis()
> - Wiki getWiki(String wikiName)
>
> Wiki:
> - addSpace(Space space)
> - removeSpace(String spaceName)
> - List getSpaces()
> - Space getSpace(String spaceName)
> - Farm getFarm()
>
> Space:
> - addDocument(Document document)
> - removeDocument(String documentName)
> - List getDocuments()
> - Document getDocument(String documentName)
> - Wiki getWiki()
>
> The same applies to Document and Object.
>
> Now the interesting part is what happens for example when
> Space.getDocuments() is called? The user will expect that it returns
> the lists of documents in the space. This requires access to the
> storage component. Thus I now believe we should have the model
> classes have the storage component injected. The alternative is
> either to not have the above-defined methods in the model classes
> (which I think would be a pity) or have some external services to
> load the data in the model objects. But that's tricky because it
> would mean loading the whole object graph at once or doing some
> tricky transparent lazy loading. Thus my preference goes to adding a
> dependency to the storage component in the model classes.
>
Here's something I don't like in the current core:
$xwiki.getDocument("Some.Doc").getObject("Some.Class", 13)
When calling this, the document, along with all its attachments,
objects, class, is completely restored from the database. If there are
500 objects, and I'm only interested in number 13, there's a complete
waste of time and memory. We should consider this when deciding how do
we retrieve stuff from the storage.

Lazy types are not good, as they are storage dependent. Hibernate has
this feature, but how about XML Database servers, or JCR? We'd
probably have to write our own storage-dependent wrappers.

On the other hand, I'd like *not* to have a storage dependency inside
the model classes. The model should only contain data.

Pros and cons of lazy loading data:
Pros
- We can reduce the amount of time/memory needed to load a document
- There's no dependency on the storage inside the model
Cons
- We need an intermediate between storage and model (decorator?)
- We might have to write the intermediate along with the storage, as
not all storage systems support lazy loading. This is not as bad as it
looks, because basically we're moving storage.load() from a model
class to a decorator class, and the decorator can be
storage-dependent.

Can we use JPOX ( http://www.jpox.org/ ) as the decorator for some
storage systems? Should we?

> * Now we'll want to cache data instead of hitting the database every
> time. We could do this in several ways: using the database cache,
> using a delegating caching storage implementation or doing the
> caching in the model classes themselves using a caching service. I'm
> not sure here but a delegation at the level of the storage component
> sounds nicer to me at first glance.
>

+1 for the storage cache. The data model should not be concerned with caching.

> WDYT?
>
> Thanks
> -Vincent
>
> On May 28, 2007, at 9:38 AM, Vincent Massol 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
> >   - (probably lots of others)
> > * As you can see I'd like to introduce the Space and Farm objects
> > * We create a model/ build module in trunks-devs/xwiki/model for
> > storing model classes
> > * Model classes cannot access other classes outside of the model/
> > module. They are meant to be used by components to provide services
> > but they shouldn't provide services themselves. They can methods to
> > manipulate their fields and they can call each other but they
> > cannot call outside of their model.
> > * We use the org.xwiki.model package for storing Model classes
> > * These model classes are all user public (API)
> >
> > WDYT?
> >
> > Barring any negative feedback I'll start implementing this today
> > and in the coming days. One question that remains unanswered in my
> > mind is how do we integrate back these model classes into the V1
> > architecture. I think we should be able to retrofit the existing
> > classes to use these classes by composition. For example the
> > Document object could have 2 fields: one org.xwiki.model.Document
> > and one org.xwiki.model.Space. The XWiki object could have 2
> > fields: Wiki and Farm, etc. I'm not sure how this would work out
> > though. Any idea is welcome.
> >
> > Thanks
> > -Vincent
> >
> >
>
>
Sergiu
--
http://purl.org/net/sergiu



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Sergiu Dumitriu
In reply to this post by vmassol
On 5/29/07, Vincent Massol <[hidden email]> wrote:

> Hi everyone,
>
> On May 29, 2007, at 5:43 PM, Stéphane Laurière wrote:
>
> > Sergiu Dumitriu wrote:
> >> On 5/28/07, Vincent Massol <[hidden email]> 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
>
>
>
We have something similar already. All model classes are derived from
BaseElement, and those that have sub-items are derived from
BaseCollection, like:

Object
 |_ BaseElement
      |____ BaseProperty
      |          |_ StringProperty, DateProperty, NumberProperty...
      |____ BaseCollection
                |_ BaseClass
                |    |_ PropertyMetaClass
                |_ BaseObject
                |_ PropertyClass

So, a Node can be the equivalent of BaseElement.

--
http://purl.org/net/sergiu


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Sergiu Dumitriu
In reply to this post by Stéphane Laurière-6
On 5/29/07, Stéphane Laurière <[hidden email]> 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 <[hidden email]> 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.
>
We can make a unified API for all these classes, and (as I said in my
previous email) we already have something similar with
BaseElement/BaseCollection. But I don't agree that this is where we
should stop. Having specific classes to ease the usage is a must. Like
Vincent said, why call node.getElementsByType(NodeType.DOCUMENT) when
we know we want the documents in a space? This is why DOM didn't stop
at Node, and it provides Attribute and Element interfaces, and even
specific interfaces for the elements in HTML.

> > XPropertyMeta
>
> What would XPropertyMeta stand for?
>

XPropertyMeta is the definition of XPropertyDefinition; a Meta lists
the various settings for the different types of properties, thus
defining what is a StringProperty, what is a NumberProperty, etc.

> With Mikhail we tried to produce a wiki model that can be easily mapped
> to the JCR model, and we came up with the following core elements:
>

Why the JCR model? Does it provide any advantages that cannot be
easily obtained with a different model? We should keep the model
independent from the actual storage, because there are lots of storage
models: relational, JCR, XML, RDF, db4o are the ones that get in my
mind right now.

> - Node (Document, XObject, Attachment would then be represented using
> Node instances)
> - NodeType (JCR terminology, equivalent to XClass)
>
> - ID: our proposal would be to create a top level class for IDs so that
> (i) can have several URIs for the same ID, (2) all manipulations with
> IDs (renaming: giving a new URI for an ID) are distinct from Node
> manipulation, (iii) this will allow the implementation of a service
> dealing only with IDs and URIs separately from the Node implementation.
>
This is something I like. We should make ID-s independent from the
name, as at the moment ID-s are strongly related to the name of the
document, classname and number of the object. And this makes renames
very hard, and aliases almost impossible.

> - Session: similar to the XWikiContext and to the JCR Session class:
> it's the user's context, giving access to all repository services
> adapted to that context.
>

Is a session part of the *data* model?

> In addition to these core elements, we should add to the model a Version
> class, but its scope remains to be discussed.
>
> Just to see where we are on the map, we also drew the comparison below
> between the XWiki2 and JCR models:
> Farm <=> JCR engine
> Wiki <=> Repository
> Space <=> Node
> Document <=> Node
> Attachment <=> Node
> XClass <=> NodeType
> XPropertyDefinition <=> PropertyDefinition
> XProperty <=> Property
> XObject <=> Node
>
>  From the discussion we had, it appears that at least Cognium Systems
> would be interested in designing core wiki libraries that could be then
> used by their collaborative engine in addition to being used by XWiki.
> Obviously, other companies and researchers are likely to take part in
> the design of such libraries, given the importance of wikis. We believe
> that such libraries would have more impact if they are maintained by a
> wide community of companies and researchers, avoiding the situation
> where a given community fears to use some library because it has too
> tight links with a single company. This has to be assessed, though. What
> do you think?
>
I agree.

> Within Nepomuk, we're currently designing such core wiki libraries. We
> will upload a Node API proposal this week, and we plan to implement it
> on top of Jackrabbit by mid-june. The more we can share efforts toward a
> sound and flexible implementation of the core services, the better, but
> obviously the XWiki2 strategy regarding the Nepomuk effort remains to be
> investigated and discussed.
>
>
>
> Stéphane and Mikhail
>
>
>
> > XPropertyDefintion XProperty
> >
> >> - (probably lots of others) * As you can see I'd like to introduce
> >> the Space and Farm objects * We create a model/ build module in
> >> trunks-devs/xwiki/model for storing model classes * Model classes
> >> cannot access other classes outside of the model/ module. They are
> >> meant to be used by components to provide services but they
> >> shouldn't provide services themselves. They can methods to
> >> manipulate their fields and they can call each other but they
> >> cannot call outside of their model. * We use the org.xwiki.model
> >> package for storing Model classes * These model classes are all
> >> user public (API)
> >>
> >> WDYT?
> >
> > Agree
> >
> >>
> >> Barring any negative feedback I'll start implementing this today
> >> and in the coming days. One question that remains unanswered in my
> >> mind is how do we integrate back these model classes into the V1
> >> architecture. I think we should be able to retrofit the existing
> >> classes to use these classes by composition. For example the
> >> Document object could have 2 fields: one org.xwiki.model.Document
> >> and one org.xwiki.model.Space. The XWiki object could have 2
> >> fields: Wiki and Farm, etc. I'm not sure how this would work out
> >> though. Any idea is welcome.
> >>
> >> Thanks -Vincent
> >
> > Agree for XWiki, but I don't know why should we have a Space object
> > in the old Document. Are there any Space methods in the current code?
> >
> >
> >
> > You have my support. As much as my time allows, I'll help you on
> > this.
> >
> > Sergiu
> >
>
>
> --
> Stéphane Laurière
> [hidden email]
>
> XWiki Research
> http://www.xwiki.com
> http://concerto.xwiki.com
> http://nepomuk.semanticdesktop.org
>
>
Sergiu
--
http://purl.org/net/sergiu


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Sergiu Dumitriu
In reply to this post by vmassol
We should also consider the following use-cases:

Class inheritance. We have User as a generic wiki user, Teacher as a
user that has a scientific title, a department, etc, Student as a user
that has a generation, an ID, a status... This can also be achieved by
placing more objects on the same page, but it's not nice, and it
certainly requires more Velocity code (I know, I had to implement
something like this). We should consider multiple inheritance and deep
hierarchies, too.

Objects with more than one class. There are some users that are both
Student and Teacher. It's not nice to explicitly create a class
inheriting both parent classes, so instead we should combine them
in-place, like an anonymous class. Another example, consider a
BlogArticle that describes an Event; we could write a single object
that will be displayed in the blog and in the EventCalendar.

Anonymous objects. We can write objects that don't have a fixed
structure, but are rather a collection of properties defined ad-hoc.

Anonymous object properties. We can add some extra properties to a
typed object, although they are not specified in the class.

Anonymous document properties. We should be able to add properties
directly to the document, not just to an object. These properties act
like document metadata.

Re-casting objects. Should we allow changing the type of an object?
For example, a Student graduated and was hired as a Professor. Also,
if we allow adding a new class to an object, do we also allow removing
one?



Observations:

The properties added to a document, or an object, should be defined
somewhere or not? Meaning, in order to add an "StartDate" property to
an object, should we define it in the wiki, or the user just enters
both the name and the value? I'd say yes, as in RDF a property must be
defined before being used.

We should be able to remove from an object anonymous properties, but
not the properties defined in the object's class.

When removing a class from an object, or recasting an object, the
properties that are no longer defined in a class should remain as
anonymous properties until manually removed?



On 5/28/07, Vincent Massol <[hidden email]> 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
>    - (probably lots of others)
> * As you can see I'd like to introduce the Space and Farm objects
> * We create a model/ build module in trunks-devs/xwiki/model for
> storing model classes
> * Model classes cannot access other classes outside of the model/
> module. They are meant to be used by components to provide services
> but they shouldn't provide services themselves. They can methods to
> manipulate their fields and they can call each other but they cannot
> call outside of their model.
> * We use the org.xwiki.model package for storing Model classes
> * These model classes are all user public (API)
>
> WDYT?
>
> Barring any negative feedback I'll start implementing this today and
> in the coming days. One question that remains unanswered in my mind
> is how do we integrate back these model classes into the V1
> architecture. I think we should be able to retrofit the existing
> classes to use these classes by composition. For example the Document
> object could have 2 fields: one org.xwiki.model.Document and one
> org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and
> Farm, etc. I'm not sure how this would work out though. Any idea is
> welcome.
>
> Thanks
> -Vincent
>
Sergiu
--
http://purl.org/net/sergiu



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Re: [ArchitectureV2] Model proposal

vmassol
Administrator
In reply to this post by Sergiu Dumitriu

On May 30, 2007, at 12:59 AM, Sergiu Dumitriu wrote:

[snip]

> Lazy types are not good, as they are storage dependent. Hibernate has
> this feature, but how about XML Database servers, or JCR? We'd
> probably have to write our own storage-dependent wrappers.
>
> On the other hand, I'd like *not* to have a storage dependency inside
> the model classes. The model should only contain data.

The model should only contain data AND behaviors associated with this  
data. For example I'm pretty confident we want to have  
Space.getDocuments() for example in the model.

> Pros and cons of lazy loading data:
> Pros
> - We can reduce the amount of time/memory needed to load a document

Well this is the same as with the other option I believe as for  
example we would retrieve documents only when Space.getDocuments()  
get called the first time. Or do you mean something else?

> - There's no dependency on the storage inside the model

There's a dependency but it's a runtime dependency rather than a  
source time dependency.

> Cons
> - We need an intermediate between storage and model (decorator?)

Yes, this requires some magic (byte code enhancement) if you want to  
make it transparent. Otherwise you need an API to load data and then  
only you're allowed to use the domain objects, which isn't nice.

> - We might have to write the intermediate along with the storage, as
> not all storage systems support lazy loading. This is not as bad as it
> looks, because basically we're moving storage.load() from a model
> class to a decorator class, and the decorator can be
> storage-dependent.
>
> Can we use JPOX ( http://www.jpox.org/ ) as the decorator for some
> storage systems? Should we?

Yes we could. I know someone who's using it. I'll check with him.

[snip]

Thanks
-Vincent




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

kaaloo
In reply to this post by Ludovic Dubost
Hi everyone,

The issue of requirements seems very interesting to me with respect to this discussion.  Clearly JCR and XWiki do not have the same requirements but there is certainly a lot to be learned from a generic content repository architecture for XWiki.  My first thought is that given the importance of wiki level scripting in XWiki everything must be done to move towards an easy to use, flexible and powerful system at that level.  On the other hand, a first class citizen abstract JCR compatible content model in the core sounds like it would also have many advantages including the capacity to span different concrete repository implementations.   Actually the JCR model proposal is basically a meta model for a domain specific XWiki model at it seems we would need both to get the best of both worlds.

Now looking at this from the scripting side, it would be very cool at one point to go even further and actually be able to benefit from a solid extensible meta model in the core by mapping an XWiki application level data model composed of Wiki level classes and objects and their relationships into scripting.  For instance, let's say a project management application and being able to easily navigate between projects, tasks, milestones, resources and other application level concepts in scripting.  It seems to me that this is the type of thing that could be enabled at one point by having a solid meta model in place like the one suggested by Stéphane.

Luis

On 5/29/07, Ludovic Dubost <[hidden email]> 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 <[hidden email]> 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 [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto: [hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws




--
Luis Arias
http://www.xwiki.com
+33 6 14 20 87 93
skype : kaaloo

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Re: [ArchitectureV2] Model proposal

Sergiu Dumitriu
In reply to this post by vmassol
On 5/30/07, Vincent Massol <[hidden email]> wrote:

>
> On May 30, 2007, at 12:59 AM, Sergiu Dumitriu wrote:
>
> [snip]
>
> > Lazy types are not good, as they are storage dependent. Hibernate has
> > this feature, but how about XML Database servers, or JCR? We'd
> > probably have to write our own storage-dependent wrappers.
> >
> > On the other hand, I'd like *not* to have a storage dependency inside
> > the model classes. The model should only contain data.
>
> The model should only contain data AND behaviors associated with this
> data. For example I'm pretty confident we want to have
> Space.getDocuments() for example in the model.
>
Of course. Data alone = storage.

> > Pros and cons of lazy loading data:
> > Pros
> > - We can reduce the amount of time/memory needed to load a document
>
> Well this is the same as with the other option I believe as for
> example we would retrieve documents only when Space.getDocuments()
> get called the first time. Or do you mean something else?
>

Not quite. Space.getDocuments can do:
1. load from the storage all the documents in that space
2. load a lazy list that reflects the number of documents in the
database. When we try to access an entry in the database, we load that
document, and only that document.

> > - There's no dependency on the storage inside the model
>
> There's a dependency but it's a runtime dependency rather than a
> source time dependency.
>

The dependency is hidden inside the decorator, and isn't visible in
the model classes. So yes, it's a runtime dependency.

> > Cons
> > - We need an intermediate between storage and model (decorator?)
>
> Yes, this requires some magic (byte code enhancement) if you want to
> make it transparent. Otherwise you need an API to load data and then
> only you're allowed to use the domain objects, which isn't nice.
>

I don't understand what "domain objects" are. Can you explain?

> > - We might have to write the intermediate along with the storage, as
> > not all storage systems support lazy loading. This is not as bad as it
> > looks, because basically we're moving storage.load() from a model
> > class to a decorator class, and the decorator can be
> > storage-dependent.
> >
> > Can we use JPOX ( http://www.jpox.org/ ) as the decorator for some
> > storage systems? Should we?
>
> Yes we could. I know someone who's using it. I'll check with him.
>
> [snip]
>
> Thanks
> -Vincent
>
Sergiu
--
http://purl.org/net/sergiu



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Re: [ArchitectureV2] Model proposal

vmassol
Administrator

On May 30, 2007, at 11:54 AM, Sergiu Dumitriu wrote:

[snip]

>> > Pros and cons of lazy loading data:
>> > Pros
>> > - We can reduce the amount of time/memory needed to load a document
>>
>> Well this is the same as with the other option I believe as for
>> example we would retrieve documents only when Space.getDocuments()
>> get called the first time. Or do you mean something else?
>>
>
> Not quite. Space.getDocuments can do:
> 1. load from the storage all the documents in that space
> 2. load a lazy list that reflects the number of documents in the
> database. When we try to access an entry in the database, we load that
> document, and only that document.
Ok I agree but this can be done with either solutions. So I think we  
agree we want to have the Space.getDocuments() methods in the model  
classes and calling them will return database data (either when they  
are called or when the relationship is navigated).

>> > - There's no dependency on the storage inside the model
>>
>> There's a dependency but it's a runtime dependency rather than a
>> source time dependency.
>>
>
> The dependency is hidden inside the decorator, and isn't visible in
> the model classes. So yes, it's a runtime dependency.

One drawback is that you need to tell somewhere where you want the  
interceptor to plug into. This can be done with a configuration file  
(I don't know how jpox does it) or it can be done using some  
annotation. In that case we come back to a source dependency but it  
has the advantage of being more maintainable (otherwise you need to  
ensure you config file and your class/methode names are always in sync).

>> > Cons
>> > - We need an intermediate between storage and model (decorator?)
>>
>> Yes, this requires some magic (byte code enhancement) if you want to
>> make it transparent. Otherwise you need an API to load data and then
>> only you're allowed to use the domain objects, which isn't nice.
>>
>
> I don't understand what "domain objects" are. Can you explain?

I meant model classes.

[snip]

Thanks
-Vincent



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Re: [ArchitectureV2] Model proposal

Catalin Hritcu
In reply to this post by Sergiu Dumitriu
Hi,

On 5/30/07, Sergiu Dumitriu <[hidden email]> wrote:

> On 5/29/07, Vincent Massol <[hidden email]> wrote:
> > Some more details on this topic:
> >
> > * We should have a consistent naming. Either we use XObjects/XClass
> > and then we have to use X in front of everything: XFarm, XWiki
> > (funny), XSpace, XDocument, etc or we agree that the namespace is
> > enough (org.xwiki.model) to indicate that these are all XWiki classes
> > and we drop the X. This is my preference. When we write documentation
> > we can refer to XObjects/XClass/ to separate them from Java Objects/
> > Class though.
> >
>
> I'm for the second option, with the minor objection that I don't like
> having an Object class. Name collision with the most used class in the
> Java world. But I can deal with this inconvenience.
>
Sorry if I seem picky about a naming issue, but I think that naming
any class Class or Object is _extremely_ confusing, not only in the
discussions but also when reading code.  One of the many reasons is
that the java.lang package doesn't need to be imported explicitly. We
already had a proposal we accepted to call them XClass and XObject:
http://mail-archive.objectweb.org/xwiki-dev/2007-04/msg00073.html

I think that naming consistency should not come at the expense of
clarity. And if you still want naming consistency then I suggest
calling them MetaClass and MetaObject, instead of perpending all the
other concepts by an "X".

Regards,
Catalin



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Re: [ArchitectureV2] Model proposal

vmassol
Administrator

On May 31, 2007, at 7:17 PM, Catalin Hritcu wrote:

> Hi,
>
> On 5/30/07, Sergiu Dumitriu <[hidden email]> wrote:
>> On 5/29/07, Vincent Massol <[hidden email]> wrote:
>> > Some more details on this topic:
>> >
>> > * We should have a consistent naming. Either we use XObjects/XClass
>> > and then we have to use X in front of everything: XFarm, XWiki
>> > (funny), XSpace, XDocument, etc or we agree that the namespace is
>> > enough (org.xwiki.model) to indicate that these are all XWiki  
>> classes
>> > and we drop the X. This is my preference. When we write  
>> documentation
>> > we can refer to XObjects/XClass/ to separate them from Java  
>> Objects/
>> > Class though.
>> >
>>
>> I'm for the second option, with the minor objection that I don't like
>> having an Object class. Name collision with the most used class in  
>> the
>> Java world. But I can deal with this inconvenience.
>>
>
> Sorry if I seem picky about a naming issue, but I think that naming
> any class Class or Object is _extremely_ confusing, not only in the
> discussions but also when reading code.  One of the many reasons is
> that the java.lang package doesn't need to be imported explicitly. We
> already had a proposal we accepted to call them XClass and XObject:
> http://mail-archive.objectweb.org/xwiki-dev/2007-04/msg00073.html
>
> I think that naming consistency should not come at the expense of
> clarity.
In that case they shouldn't be named XClass and XObject because this  
doesn't mean much. In no time we'll start calling XWiki developers X-
Men... ;-)

If we want to say "XWiki Class/Object" they should be named  
XWikiClass and XWikiObject. Same for Document, Space, Farm, etc  
because for example Document can be confused with DOM Document class,  
and we can probably find other libraries using Space, Farm, etc.

Personally Class/Object doesn't bother me as it's in a separate  
namespace.

> And if you still want naming consistency then I suggest
> calling them MetaClass and MetaObject, instead of perpending all the
> other concepts by an "X".

Yes, that's a good idea. If we wanted to go that way, we could also  
call them something more business oriented like Definition (for  
Class) and DocumentMetadata (for Object).

But I'm not 100% convinced yet we need to rename them.

We can think about it. For now I think the most important decision is  
deciding what we do with Stephane's proposition of a JCR-like model.

Thanks
-Vincent




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

vmassol
Administrator
In reply to this post by vmassol
ok I'll try to summarize my current thinking after all the exchanged  
emails:

* I don't think we should model our Model classes using a similar API  
as the JCR one. I much prefer we have an expressive Model with a  
strongly typed API, with objects like Document, Space, MetaData,  
Farm, Wiki, etc. Stephane, I keep turning this in my head and I can't  
figure a good reason to have a JRC like API for our model. Maybe  
you're seeing something that I don't see? Ludovic also said "[...]  
quite a few benefits to have our objects comply with the JCR model".  
I don't see them so maybe someone could enlighten me.

* Our model classes should call the storage interface for any methods  
requiring storage access (for example: Space.getDocuments()). If  
other services are required they should be called out too. We still  
need to define a rule for when a new method can be added to the model  
classes and when a new component should rather be created. I have  
some ideas but I'm not 100% sure here so I'd like to hear what you  
think.

* I think it would be a good idea to have our model defined  
independently of the language (for example in XML - Here's for  
example the Maven model defined in xml:
http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/ 
src/main/mdo/maven.mdo

The reason is that this will allow us to generate lots of things from  
this model:
- Java bindings
- XSD
- Documentation
- Any other language bindings
- etc

We could use Modello for doing this. It's well integrated into Maven2  
and is easy to use.

* I don't think we should use JPOX. Jason, whom I trust, says it's  
been a bad decision for Continuum (they use jpox) and that there are  
only 2 active developers for jpox which makes bugs take time to fix,  
etc. In addition, I'm not sure what this would buy us as I think we  
should have storage interface and a JCR implementation of it that  
would map to whatever underlying store is configured. Not sure where  
we would fit JPOX in there.

WDYT?

Thanks
-Vincent

On May 28, 2007, at 9:38 AM, Vincent Massol 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
>   - (probably lots of others)
> * As you can see I'd like to introduce the Space and Farm objects
> * We create a model/ build module in trunks-devs/xwiki/model for  
> storing model classes
> * Model classes cannot access other classes outside of the model/  
> module. They are meant to be used by components to provide services  
> but they shouldn't provide services themselves. They can methods to  
> manipulate their fields and they can call each other but they  
> cannot call outside of their model.
> * We use the org.xwiki.model package for storing Model classes
> * These model classes are all user public (API)
>
> WDYT?
>
> Barring any negative feedback I'll start implementing this today  
> and in the coming days. One question that remains unanswered in my  
> mind is how do we integrate back these model classes into the V1  
> architecture. I think we should be able to retrofit the existing  
> classes to use these classes by composition. For example the  
> Document object could have 2 fields: one org.xwiki.model.Document  
> and one org.xwiki.model.Space. The XWiki object could have 2  
> fields: Wiki and Farm, etc. I'm not sure how this would work out  
> though. Any idea is welcome.
>
> Thanks
> -Vincent
>
>
>
>
> --
> You receive this message as a subscriber of the xwiki-
> [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Sergiu Dumitriu
On 6/4/07, Vincent Massol <[hidden email]> wrote:

> ok I'll try to summarize my current thinking after all the exchanged
> emails:
>
> * I don't think we should model our Model classes using a similar API
> as the JCR one. I much prefer we have an expressive Model with a
> strongly typed API, with objects like Document, Space, MetaData,
> Farm, Wiki, etc. Stephane, I keep turning this in my head and I can't
> figure a good reason to have a JRC like API for our model. Maybe
> you're seeing something that I don't see? Ludovic also said "[...]
> quite a few benefits to have our objects comply with the JCR model".
> I don't see them so maybe someone could enlighten me.
>
I don't see those benefits, either. So I'm +1 for your proposal.

> * Our model classes should call the storage interface for any methods
> requiring storage access (for example: Space.getDocuments()). If
> other services are required they should be called out too. We still
> need to define a rule for when a new method can be added to the model
> classes and when a new component should rather be created. I have
> some ideas but I'm not 100% sure here so I'd like to hear what you
> think.
>

This requires less programming than writing our own lazy loaders, and
is safer than using JPOX. I wish there was a better method to hide the
storage, and still not load the complete database in memory.

Btw, space.getDocuments() returns all the documents in that space,
fully loaded? space.getDocumentsNames() loads the list of documents,
or just retrieves the names?

Regarding the latter issue, we should try to make the components as
stable as possible. After we all agree on a component, we need strong
reasons to introduce something new.

Another issue, as far as I remember, components should be interfaces.
Will the model be an interface, too, with a default implementation? Or
will it not be a component?

> * I think it would be a good idea to have our model defined
> independently of the language (for example in XML - Here's for
> example the Maven model defined in xml:
> http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/
> src/main/mdo/maven.mdo
>

+1 on that, as I'm a total adept of XML. But, what language should we
use for the definition? I'd go for XSD, as I know nothing about
Modello.

> The reason is that this will allow us to generate lots of things from
> this model:
> - Java bindings
> - XSD
> - Documentation
> - Any other language bindings
> - etc
>
> We could use Modello for doing this. It's well integrated into Maven2
> and is easy to use.
>
> * I don't think we should use JPOX. Jason, whom I trust, says it's
> been a bad decision for Continuum (they use jpox) and that there are
> only 2 active developers for jpox which makes bugs take time to fix,
> etc. In addition, I'm not sure what this would buy us as I think we
> should have storage interface and a JCR implementation of it that
> would map to whatever underlying store is configured. Not sure where
> we would fit JPOX in there.
>
OK. I mentioned JPOX only because I encountered it on several forums,
and proposed it as an alternative.

> WDYT?
>
> Thanks
> -Vincent
>
> On May 28, 2007, at 9:38 AM, Vincent Massol 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
> >   - (probably lots of others)
> > * As you can see I'd like to introduce the Space and Farm objects
> > * We create a model/ build module in trunks-devs/xwiki/model for
> > storing model classes
> > * Model classes cannot access other classes outside of the model/
> > module. They are meant to be used by components to provide services
> > but they shouldn't provide services themselves. They can methods to
> > manipulate their fields and they can call each other but they
> > cannot call outside of their model.
> > * We use the org.xwiki.model package for storing Model classes
> > * These model classes are all user public (API)
> >
> > WDYT?
> >
> > Barring any negative feedback I'll start implementing this today
> > and in the coming days. One question that remains unanswered in my
> > mind is how do we integrate back these model classes into the V1
> > architecture. I think we should be able to retrofit the existing
> > classes to use these classes by composition. For example the
> > Document object could have 2 fields: one org.xwiki.model.Document
> > and one org.xwiki.model.Space. The XWiki object could have 2
> > fields: Wiki and Farm, etc. I'm not sure how this would work out
> > though. Any idea is welcome.
> >
> > Thanks
> > -Vincent
> >
> >
> >
> >
Sergiu
--
http://purl.org/net/sergiu



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Sergiu Dumitriu
One more question.

Do the model classes perform access rights checks? Or we assume that
once they get past the API everything is OK?

I'd say that all the rights checks should be performed outside the
model; perhaps the API, as it is now.

Btw, do we keep the "API" name for the scriptable model wrapper?

On 6/4/07, Sergiu Dumitriu <[hidden email]> wrote:

> On 6/4/07, Vincent Massol <[hidden email]> wrote:
> > ok I'll try to summarize my current thinking after all the exchanged
> > emails:
> >
> > * I don't think we should model our Model classes using a similar API
> > as the JCR one. I much prefer we have an expressive Model with a
> > strongly typed API, with objects like Document, Space, MetaData,
> > Farm, Wiki, etc. Stephane, I keep turning this in my head and I can't
> > figure a good reason to have a JRC like API for our model. Maybe
> > you're seeing something that I don't see? Ludovic also said "[...]
> > quite a few benefits to have our objects comply with the JCR model".
> > I don't see them so maybe someone could enlighten me.
> >
>
> I don't see those benefits, either. So I'm +1 for your proposal.
>
> > * Our model classes should call the storage interface for any methods
> > requiring storage access (for example: Space.getDocuments()). If
> > other services are required they should be called out too. We still
> > need to define a rule for when a new method can be added to the model
> > classes and when a new component should rather be created. I have
> > some ideas but I'm not 100% sure here so I'd like to hear what you
> > think.
> >
>
> This requires less programming than writing our own lazy loaders, and
> is safer than using JPOX. I wish there was a better method to hide the
> storage, and still not load the complete database in memory.
>
> Btw, space.getDocuments() returns all the documents in that space,
> fully loaded? space.getDocumentsNames() loads the list of documents,
> or just retrieves the names?
>
> Regarding the latter issue, we should try to make the components as
> stable as possible. After we all agree on a component, we need strong
> reasons to introduce something new.
>
> Another issue, as far as I remember, components should be interfaces.
> Will the model be an interface, too, with a default implementation? Or
> will it not be a component?
>
> > * I think it would be a good idea to have our model defined
> > independently of the language (for example in XML - Here's for
> > example the Maven model defined in xml:
> > http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/
> > src/main/mdo/maven.mdo
> >
>
> +1 on that, as I'm a total adept of XML. But, what language should we
> use for the definition? I'd go for XSD, as I know nothing about
> Modello.
>
> > The reason is that this will allow us to generate lots of things from
> > this model:
> > - Java bindings
> > - XSD
> > - Documentation
> > - Any other language bindings
> > - etc
> >
> > We could use Modello for doing this. It's well integrated into Maven2
> > and is easy to use.
> >
> > * I don't think we should use JPOX. Jason, whom I trust, says it's
> > been a bad decision for Continuum (they use jpox) and that there are
> > only 2 active developers for jpox which makes bugs take time to fix,
> > etc. In addition, I'm not sure what this would buy us as I think we
> > should have storage interface and a JCR implementation of it that
> > would map to whatever underlying store is configured. Not sure where
> > we would fit JPOX in there.
> >
>
> OK. I mentioned JPOX only because I encountered it on several forums,
> and proposed it as an alternative.
>
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > On May 28, 2007, at 9:38 AM, Vincent Massol 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
> > >   - (probably lots of others)
> > > * As you can see I'd like to introduce the Space and Farm objects
> > > * We create a model/ build module in trunks-devs/xwiki/model for
> > > storing model classes
> > > * Model classes cannot access other classes outside of the model/
> > > module. They are meant to be used by components to provide services
> > > but they shouldn't provide services themselves. They can methods to
> > > manipulate their fields and they can call each other but they
> > > cannot call outside of their model.
> > > * We use the org.xwiki.model package for storing Model classes
> > > * These model classes are all user public (API)
> > >
> > > WDYT?
> > >
> > > Barring any negative feedback I'll start implementing this today
> > > and in the coming days. One question that remains unanswered in my
> > > mind is how do we integrate back these model classes into the V1
> > > architecture. I think we should be able to retrofit the existing
> > > classes to use these classes by composition. For example the
> > > Document object could have 2 fields: one org.xwiki.model.Document
> > > and one org.xwiki.model.Space. The XWiki object could have 2
> > > fields: Wiki and Farm, etc. I'm not sure how this would work out
> > > though. Any idea is welcome.
> > >
> > > Thanks
> > > -Vincent
> > >
> > >
> > >
> > >
>
> Sergiu
> --
> http://purl.org/net/sergiu
>

--
http://purl.org/net/sergiu



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
12