Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-09-01 Thread Edgar Poce
Hi, On 8/31/06, Christophe Lombart [EMAIL PROTECTED] wrote: 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. thanks for joining :) 3/ JCR API is low level and verbose for a business developers. The

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-31 Thread Christophe Lombart
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

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-28 Thread Jukka Zitting
Hi, On 8/28/06, Edgar Poce [EMAIL PROTECTED] wrote: On 8/27/06, Jukka Zitting [EMAIL PROTECTED] wrote: I'm not too familiar with the Alfresco codebase, but that's also a possible alternative to look at. IANAL but have you seen the license?, I don't think I could ever use it :( Ah, too bad,

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-27 Thread Edgar Poce
Hi Michi, On 8/26/06, Michael Wechner [EMAIL PROTECTED] wrote: well, it might depend on how much one believes in JCR as one fits all solution. I don't believe that JCR is a one fits all, actually you'll find many posts to jackrabbit ML from me where I try to explain problems I faced while

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-27 Thread Jukka Zitting
Hi, On 8/27/06, Edgar Poce [EMAIL PROTECTED] wrote: On 8/26/06, Michael Wechner [EMAIL PROTECTED] wrote: Even if JCR is a great thing, it might not fit all purposes and one might be glad to have an alternative entry point, I agree with you. However I tend to think JCR is a good match for

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-27 Thread Jukka Zitting
Hi, On 8/27/06, Edgar Poce [EMAIL PROTECTED] wrote: To name a few first hand problems I faced: [...] That's a very good summary of the problem areas I've been facing as well. Would you like to follow up with that on the Jackrabbit mailing list? I think it would make for a great discussion

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-27 Thread Edgar Poce
Hi David, On 8/26/06, David Sean Taylor [EMAIL PROTECTED] wrote: 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 JCR API.

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-27 Thread Edgar Poce
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

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-27 Thread Edgar Poce
On 8/27/06, Jukka Zitting [EMAIL PROTECTED] wrote: I'm not too familiar with the Alfresco codebase, but that's also a possible alternative to look at. IANAL but have you seen the license?, I don't think I could ever use it :( from http://dev.alfresco.com/legal/licensing/apl/ .. However, in

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-25 Thread Edgar Poce
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

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-08-25 Thread David Sean Taylor
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

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-07-21 Thread Christophe Lombart
On 7/21/06, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 7/21/06, Jukka Zitting [EMAIL PROTECTED] wrote: Going deeper into the graffito-api project I started wondering why it contains the Webdav-, Graffito- and FileSystemServer interfaces? I traced the use of the Server interface back to

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-07-21 Thread Jukka Zitting
Hi, On 7/21/06, Christophe Lombart [EMAIL PROTECTED] wrote: Right - There are simple data objects to store connection setting parameters. OK, that clears things. Do the Servers need to be interfaces, i.e. do you expect multiple different implementations of the data object classes? I'm on

Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-07-20 Thread Jukka Zitting
Hi, Going deeper into the graffito-api project I started wondering why it contains the Webdav-, Graffito- and FileSystemServer interfaces? And more alarmingly, why does the ContentServerService interface contain factory methods to generate instances of those interfaces? My understanding from

Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?

2006-07-20 Thread Jukka Zitting
Hi, On 7/21/06, Jukka Zitting [EMAIL PROTECTED] wrote: Going deeper into the graffito-api project I started wondering why it contains the Webdav-, Graffito- and FileSystemServer interfaces? I traced the use of the Server interface back to just providing configuration interface to the