incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <>
Subject Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Date Sun, 27 Aug 2006 13:45:02 GMT

On 8/27/06, Edgar Poce <> wrote:
> On 8/26/06, Michael Wechner <> 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.


Jukka Zitting

Yukatan - -
Software craftsmanship, JCR consulting, and Java development

View raw message