On 7/12/2010 8:57 AM, Ean Schuessler wrote:
Adrian Crum wrote:
we need is a factory for javax.jcr.Repository, and that
could be put in the content component.
I would really prefer to not mix components for a couple of
reasons:
- Some of the existing content stuff should have been in
the framework IMO
- Mixing old and new in a single component is going to get
messy
I would really rather see the repository and its associated
low level tools become part of the framework. I don't
care what we call it, jackrabbit was just the easy choice at
the time.
I'm trying to understand what we want out of a Jackrabbit integration.
I'm sure everyone has something different that they want out of it. My
involvement will be very specific: Give OFBiz the ability to serve
content from external content repositories. From my perspective, the
Jackrabbit integration provides a test bed for JCR-compliant content
repository integration.
Enterprises may have repositories scattered all over the company. Having
OFBiz serve content from all of them will be useful.
The API for accessing OFBiz content is definitely not a comfortable one
but I wonder if that isn't more of a reflection of its entities being
overly complicated. The DataResource/Content separation has its uses but
definitely makes creating content systems less than intuitive.
I'm not 100 percent sure, but I think one of the goals is to have JCR
replace the existing OFBiz content API stuff.
My concern with JackRabbit is similar to concerns I have with Lucene as
a search system, which is the disconnection between the layers. It seems
like it becomes more complicated to join business data against "content"
once these things are disconnected and that we will end up writing more
glue code to bring them back together.
When we started our Webslinger work, JSR-283 was not as popular as it is
now and we settled on CommonsVFS as a filesystem abstraction layer. I've
looked at JSR-283 fairly closely and its an interesting device but has
its quirks. Its ability to associate multiple streams of content with a
single URL is interesting but departs from the conventional way people
think of file systems. Whether this is a bug or a feature isn't clear to me.
It makes things more convenient for the repository user. Picture a
remote server's file system being mapped to a folder in a local file
system. Where the files physically reside is transparent to the user.
Watch the movie:
http://www.day.com/day/en/products/crx.html
One of the things that seems very important to me is the ability to have
strong file-based content handling because that is the most common mode
of data exchange. The WebDAV features of JackRabbit are an interesting
possible replacement but I'm not clear that it really represents a
full-fledged substitute for file based content management.
I wouldn't relish writing a binding for Jackrabbit to the existing
content entities though it seems like they could accommodate it.
I agree with you. I don't know why anyone would want to do that, except
maybe to support legacy data in the content entities.
It might be worth looking at the existing JackRabbit JDBC bindings and
creating identical EntityEngine entities. That should make a port of the
JDBC based back-end to the entity engine straightforward. This would
have the benefit of supporting ECAs automatically, maintaining full SQL
compatibility and preserving the ability to query content with the
entity engine interface.
The one significant benefit to wrapping the existing content classes
with JackRabbit would be the ability to immediately query existing
system content with the easier to manage JackRabbit API. We would have
to construct some kind of programmatic namespace to connect in stores,
parties and other content to the JackRabbit root but it could make
working with the content system much easier.
