Hi,
On 8/27/06, Edgar Poce <[EMAIL PROTECTED]> wrote:
On 8/26/06, Michael Wechner <[EMAIL PROTECTED]> wrote:
> Even if JCR is a great thing, it might not fit all purposes and one
> might be glad to have an alternative entry point,
I agree with you. However I tend to think JCR is a good match for
graffito. As far as I see in the sources most of the API/impl
development effort was put on coding a subset of the features
jackrabbit already provides. I guess that in case JCR is chosen as the
only api to interact with the repository the development effort could
focus on implementing the portlets for content management, and
eventually adding features to the underlying jcr implementation.
The JCR API is unfortunately not too easy to implement on top of
existing content repositories or content access mechanisms. My
understanding is that the goal of the API is more to provide a
standard and feature-rich platform for building new content
applications rather than to be a lowest common denominator for easy
integration with all existining content stores.
Thus, until (or if ever) there are readily available implementations
of JCR on top of filesystems, generic databases, WebDAV, etc. I think
it makes sense for Graffito to have it's own abstraction layer
especially when the goal is to be able to work with a number of
different backends.
My concern for starting this thread was more related to the structure
of the Graffito abstraction layer. I still don't quite see the
rationale for using interfaces for plain data objects and the need for
explicitly modelling the (configuration of) possible backend systems
as separate Server interfaces.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
