-----Original Message----- From: Christophe Lombart [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:06 AM To: graffito-dev@incubator.apache.org Subject: Re: Graffito status followup
Hi Jukka, Let's start to grasp the underlying idea of Graffito. I agree with you to clarify this point. Maybe this is not yet defined. When we will be agree on the Graffito goals, we can try to review together the architecture and see later if we have to split the project or review some parts to be more attractive. I would like to see Graffito as a series of components/services to build ECM applications. that's all :-) In my point of view, we need the following layers : a. "Graffito Core" : all necessary low-level services to define, store, manage, audit, request and search content. If needed, it can give an access to different heterogenous content servers (JCR and propriatary servers). Graffito core have to be extensible. For example, a workflow service could be added into "Graffito Core". b. "Graffito Runtime" : it should be possible to deploy the "Graffito Core" anywhere and customize the components to use. Generally, the "Graffito core" is matching to a content server or a cluster of content server. c. "Graffito Applications" : a series of applications which access to "Graffito Core" to manage a specific kind of content application. Some basic applications can be a simple document management, a forum or a wiki application. Advanced web content management can be also a good example. I think Graffito applications are also components/service based. d. "Graffito portlets" : a series of portlets used to integrate "Graffito applications" into portal like Jetspeed. Is it make sense ? Do you see some point to improve ? If we are agree on the underlying ideas, let's start the technical details. Just one word in point of view of architecture, I'm not the SOA expert but I'm wondering if we can go into this direction. br, Christophe Good morning, I've been lurking on this list for a while, trying to better grok where the Graffito project is and where it's going. I was working on my own Object<-> JCR mapping project, so Graffito is of great interest to me. So here's my $.02. I agree that the underlying idea of Graffito and consensus on this is essential. On point a I mostly agree - with the exception of the workflow comment. Via listeners etc I think there are ample places to hook workflow into JCR in general, and there are a number of workflow engines out there. As such, tying anything other than the most bare workflow notions into Graffito limits its use, or at least has users ignoring a bunch of the work in the core. Yes, the core has to be extensible, but spending too much time on extensibility prior to an actual release just pushes the release farther and farther out. On point c - couldn't agree more. This gets you to, essentially, a series of clients that each manages a particular domain model and a series of use cases. This is where extensibility is key, as folks will always want "one more property" that you haven't thought of. In this arena there is something of an interesting need too related to extensibility, and that is a common node definition lang. Several other jcr backed applications have a node def lang (ie: CND for Jackrabbit, whatever-it-is for alfresco, etc), and a wonderful extension point for Graffito to allow and promote domain specific node defs etc would be a more common way to express the node/property structure. This could be similar to how Hibernate uses the notion of dialects to generate RDMS specific DDL for db creation from its standard mappings. On point d - I've liked the notion of portlets for a long time, but I think the too tightly coupling the notion/power of Graffito (general Object<->JCR mapping tool) to portals has stalled its appeal to a larger audience of developers. This goes along with the sentiment that Graffito could/should be more properly aligned beneath Jackrabbit than the portals project. Portals and portal content are a specific domain that JCR is good at managing, but not the core reason the spec was defined. If the focus is narrow - Object<->JCR, then building applications on top of that to address specific domains should be much easier. So, I've certainly dumped my opinions - I apologize if I've offended or stepped out of bounds. Thanks, Brian -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.25/669 - Release Date: 2/4/2007 9:58 PM
