Hi, On 8/27/06, Edgar Poce <[EMAIL PROTECTED]> 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. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
