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 20:59:38 GMT

On 8/27/06, Edgar Poce <> wrote:
> 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?

I think the main point is to allow the use of different backend stores
for the Graffito content. So even though the Graffito object model is
somewhat fixed (see the CmsObject hierarchy), the idea is to allow the
object model to be transparently saved on a combination of different
backend stores based on custom configuration.

I'm unfortunately not yet familiar enough with Graffito to comment on
your other questions and alternatives. Perhaps others can step in and
enlighten us.

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

+1 I'd very much like to see simple JCR-over-filesystem,
JCR-over-webdav, and JCR-in-memory repository implementations based on
some simple repository framework. As you mentioned, Jackrabbit core is
probably too monolithic to do that, so an alternative approach like
the early drafts I did for jcr-ext or the current JCR SPI effort could
be a good starting point. I'm not too familiar with the Alfresco
codebase, but that's also a possible alternative to look at.


Jukka Zitting

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

View raw message