incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <>
Subject Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Date Sat, 26 Aug 2006 04:43:21 GMT
When we founded Graffito, our goal was to provide a generalized CMS API 
to all CMS backends for our web applications. At the time, JCR was not 
public.  The APIs in Graffito today have been around for over four years 
in their general form. They are used in production (with proprietary 
implementations behind them). In short, they are very simple, straight 
forward CMS APIs that really haven't required a lot of change over the 
years. Since then, JCR has come out, but these APIs still do exist.

A second goal was to provide a set of portlets for generalized 
navigation, interaction and administration of content. A third goal was 
for normalized URI access to portlet content, such as the ability to 
mount heteregenous CMS systems onto the same URI space in a portal. The 
fourth goal was to integrate a common security model between the portal 
and content.

After the project was established, the community developed a 
content-to-business-object-mapping framework. This framework makes 
developing business applications, in the presentation layer (such as 
portlets) more natural for developers to productively work than directly 
programming to the JCR API, which is abstract in comparison.

There is no question in my mind that goals two, three, and four are 
still relevant areas. The first goal, the API should be discussed. I 
have personally never used the mapping framework, but from what I hear, 
its a very cool contribution.

If we decide that the Graffito API is redundant and no longer necessary 
to maintain, then an effort would need to be made to deprecate the API, 
and move the graffito portlet applications written to that API to the 

You also touched upon a point that has value to me: the hub of 
repositories. In my project, we have the ability to add new repositories 
to the server, and maintain the connection information with a set of 
maintenance portlets. We have a need for this kind of modeling. I 
believe its a good area for Graffito, since its about management of 
content in the model and presentation layer.

Edgar Poce wrote:
> Hi,
>  I'm working in a project that uses j2, we plan to keep using it in
> the near future and we'd like to use the cms features described in
> graffito's web page. I browsed the sources and I have the same doubt
> that started this thread.
>  I don't understand what's the purpose of the webdav\filesystem\ojb
> servers. I think one of the purposes of jcr is to provide that layer
> on top of existing repositories. Moreover, most of the services the
> graffito api provides seem overlapped with jcr.
>  My understanding is that most CMS features belong to a layer on top
> of jcr. Is there any reason for not using jcr as the only api to
> interact with the repository and build services on top of it?
>  In any case, if there's the intention of building a repository that
> works as a hub of plugged server implementations, why not to build
> that integration layer as a JCR implementation leaving the CMS unaware
> of that?.
> thanks in advance,
> edgar

View raw message