incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Date Thu, 31 Aug 2006 08:44:37 GMT
Hi Edgar,

Sorry for the delay but I was on vacation.

I don't know if it is possible to join this thread now but let me give
you my point of view on JCR integration and object oriented design.

Sometime, it could be interesting to have some JCR Portlets like the
JCR browser but I'm not sure that "business" portlets (or other kind
of applications) like a news management, DM, .. are good candidates to
use directly the JCR API for the following reasons :

1/ There are max 5 JCR impl on the market. Ok, we can expect to see
more and more implementations.

2/ The JCR API  can change due to some current "user" issues as you explained..

3/ JCR API is low level and verbose for a business developers. The
Graffito API is more simple for a business developer. I'm just curious
to know you point of view on that.

4/ One of the most important Graffito goals is to make abstraction on
the repository nature. Users who have specific content repo can use
Graffito. There need a new Server impl and a new ContentStore
implementation. If needed, you can review some issues in this area.

So, now the real question is :
Is it interesting to use a High level object model for my content application ?
Personally, I would like to review in more details your point of view
before taking a decision. Your are argument are very good but I need
more time and experience to make my final choice. Why not ot make a
prototype based on your ideas ?

Anyway, JCR admin tools are interesting and all contribution are
welcome in this area.

br,
Christophe




On 8/27/06, Edgar Poce <edgarpoce@gmail.com> wrote:
> 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
> >
>


-- 
Best regards,

Christophe

Mime
View raw message