incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce" <edgarp...@gmail.com>
Subject Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Date Sun, 27 Aug 2006 16:14:45 GMT
Hi,

On 8/27/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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.

I think I'm missing something here. For what I see the GFT API is not
used as an interface to integrate legacy data, its intention seems to
be to hide the implementation details of strategies that are optimized
for different persistent storages. However, based on David comments it
seems that there are propietary integration implementations. Sorry for
the noise in case I'm missing something obvious. comments?

> 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.
>

Not sure, but is it worth to lose a feature rich api as JCR under an
abstraction layer with the goal of using different low level
strategies for storing content?.

Not sure, but if the development effort is so high both for building a
level 1 jcr implementation for integration purposes and for
maintaining a custom API, wouldn't it be a better choice to build
custom ETLs to synchronize the repository with external content rathen
than mantaining a custom API?. Also not sure, but if the portlets are
built on top of JCR there will probably be more interest from the
community to colaborate, since it could be reused in other portals,
repositories, right?.

A first example that come to my mind of a drawback and lose of code
reuse is the repository browser. Now, the GFT repository browser uses
it's custom api, wouldn't it be a better choice to build a generic JCR
repository browser?, actually there's already an open source desktop
implementation based on the eclipse platform. In case GFT uses JCR
that and other software could be reused. Given the fact that I still
don't fully agree with some decisions It's probably too early to offer
a contribution, but I volunteer give a try to code a web based JCR
repository browser for graffito in case there's interest.

And the last but not least "not sure" :), wouldn't it make sense to
build a framework for implementing level 1 repositories?, I think your
contribution to jackrabbit, jcr-ext, would be a starting point, has it
any sense?

> 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.
>

I fully agree with you on this.

br,
edgar

> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>

Mime
View raw message