[dna-dev] JBoss DNA 0.4 planning

[Michael Neale]

there is drools-repository - it does have a few jackrabbit specific
things to do with the setup of node types (as its not defined by the
JCR spec) - would be interesting to see it.

Is there a limit to the subset of JCR features you are supporting?

On Tue, Nov 18, 2008 at 10:03 AM, Randall Hauch <rhauch at redhat.com> wrote:
> Hopefully just before 0.4 we'll be able to compare DNA and Jackrabbit
> performance.  I really can't wait to see some numbers.
>
> Oh, and regarding performance tests, I'd love for people to contribute JCR
> clients (e.g., classes that take a Repository) that automatically populate
> then use the repository content.
>
> Best regards,
>
> Randall
>
> On Nov 17, 2008, at 4:53 PM, Michael Neale wrote:
>
>> Sounding good. I am quite interested in this. Will be interesting to
>> see how this works out.
>>
>> On Tue, Nov 18, 2008 at 7:20 AM, Randall Hauch <rhauch at redhat.com> wrote:
>>>
>>> On Nov 17, 2008, at 2:17 PM, Stefano Maestri wrote:
>>>>
>>>> Randall Hauch wrote on 04/11/08 19:37:
>>>>>
>>>>> Now that 0.3 is almost out the door, I'd like to start discussing the
>>>>> goals for the next release.
>>>>>
>>>>>  * I'd love to see the JCR implementation take more shape.  Right
>>>>>   now it's read-only, so getting that much farther along would be
>>>>>   outstanding.  Anybody interested?  I think we could easily put
>>>>>   several people to work here.  The graph API is pretty good, and
>>>>>   should make implementing JCR relatively straightforward.  Any
>>>>>   interest, Michael Trezzi and Alexandre and Serge?
>>>>>
>>>> I'm definitively interested contributing here also because a starting
>>>> project for my daytime job will need DNA will support JCR writing. BTW
>>>> which kind of writing would we support in this release? Just on local
>>>> filesystem I guess.
>>>> Any plan for different kind of writing like relational DB or distributed
>>>> writing (hadoop for example)?
>>>
>>> Actually, this "writing" that we should support in 0.4 was referring to
>>> the
>>> parts of the JCR implementation that change the graph.  Right now, the
>>> JCR
>>> implementation only has implementations for the "read" methods.
>>> Architecturally, the JCR implementation uses our new Graph API introduced
>>> in 0.3.  The idea is that the JCR implementation works with everything as
>>> graph content managed by a connector.  Even the NodeTypeManager would be
>>> implemented on top of the Graph API.  Events may also be addressed in
>>> 0.4,
>>> but versioning, search and query would likely be handled in 0.5.
>>>  (Actually,
>>> if that's true, then 0.5 might actually be 1.0).
>>>
>>> Now, you asked about plans for storing graph content in a relational DB
>>> or
>>> other systems (e.g., Hadoop).  Just to be clear, the Graph API already
>>> supports reading and writing, and we'll be adding events in 0.4.  The
>>> only
>>> 0.3 connector that supports persisting content is the JBoss Cache
>>> connector
>>> (relying upon JBoss Cache's ability to persist the cache content in a
>>> relational database or file system).  But I'm already working on a new
>>> connector that stores graphs in a relational database using JPA (using
>>> Hibernate for the implementation).  Hopefully that will be available
>>> soon.
>>>
>>>>> We can either tackle several things at once and move them all
>>>>> incrementally, or we can do more in just a few areas.
>>>>
>>>> My personal thoughts are that we need a strong effort for a complete JCR
>>>> implementation.
>>>
>>> Yes, I agree.  The question is if multiple people are working on the JCR
>>> implementation, do they collaborate on one feature at a time, or do they
>>> each work on their own part of the JCR implementation?  I don't have a
>>> preference, but would like those wanting to work on the JCR
>>> implementation
>>> to decide.
>>>
>>>> I'll post very soon what my daytime project is and how it's related on
>>>> DNA, since I think it could be of some interest for the whole community
>>>> being one of the first enterprise project that would use DNA quiet
>>>> extensively.
>>>
>>> Wonderful!  Can't wait to see it.
>>>
>>> Best regards,
>>>
>>> Randall
>>>
>>> _______________________________________________
>>> dna-dev mailing list
>>> dna-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/dna-dev
>>>
>>
>>
>>
>> --
>> Michael D Neale
>> home: www.michaelneale.net
>> blog: michaelneale.blogspot.com
>
>



-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com