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 <[EMAIL PROTECTED]> wrote:
Hi, On 8/27/06, Jukka Zitting <[EMAIL PROTECTED]> 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/ - [EMAIL PROTECTED] > Software craftsmanship, JCR consulting, and Java development >
-- Best regards, Christophe
