incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce" <>
Subject Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Date Sun, 27 Aug 2006 13:28:47 GMT
Hi Michi,

On 8/26/06, Michael Wechner <> 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 trying to use the api/jackrabbit for situations that don't
fit very well [see bellow]. Unfortunately it's something I learned
after seeing problems while testing my applications.

> 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
graffito. As far as I see in the sources most of the API/impl
development effort was put on coding a subset of the features
jackrabbit already provides. I guess that in case JCR is chosen as the
only api to interact with the repository the development effort could
focus on implementing the portlets for content management, and
eventually adding features to the underlying jcr implementation.

> but I cannot really judge
> because I do not Graffito well enough

  Me neither, I'm just a newbie in Graffito and CMSs in general trying
to understand the internals to see where graffito is heading and what
I can expect from it and contribute to it in the near future.

 To name a few first hand problems I faced:

  1. data aggregation is not taken into account neither in the api nor
in jackrabbit. It's very slow to try to summarize properties of a big
number of nodes, RDBMS are far more useful for this kind of use case.

 2. Jackrabbit is not optimized for data models that contains big
collections, in jackrabbit ML users are often invited to review the
data model when they face problems caused by this.

  3. Scalability, "implicit clustering" as is called in jackrabbit ML
can be easily achieved with any kind of simple master/slave
replication mechanism, however clustering with session replication and
fail over seem to be hard to achieve. On the contraty with ORM tools
like hibernate it's very easy.

 4. IMHO the jackrabbit design is pretty much coupled and it's quite
hard to tune the internals to fit specific needs.

btw, recently I read some posts on Cosmo ML about moving from JCR to a
more classic RDBMS approach due to scalability issues and learning
curve for jcr newcomers, you'll surely find more info about these
kinds of problems in cosmo ML.

>From a more general point of view I think JCR is not a good match for
designs that are very Object oriented. I think jcr features are better
used when the design treats the contents separately from the business
logic. I think that a CMS that works on top of JCR should be mostly
behavior agnostic. I mean that the business logic can be modelled not
as verbs in objects that maps to an x persistent storage but as
business processes that modify the underlying content.

e.g. in a DMS there might be no need for a Document object, but
there's the "document" data type that contains the properties and
constraints of that kind of content, and there are processes that
manage the lifecycle of that content given specific business needs.
Going deeper to implementation details I guess it could be implemented
by a process that listens and secures the content according to
business rules and fires events when the process is invoked from any
interface, either from a portal with cms portlets, or from a network
interface invoked by a user touching the content via any protocol
(webdav, nfs, cifs, ftp, smtp, ldap, etc.).

I'm probably wrong, as I told I consider myself a newbie, but IMHO
that would be a data centric application that take full advantage of
the api, a CMS that provides a GUI to manage those objects split in
content plus processes.

sorry for the long post and thanks for the feedback,

> Just my 2 cents
> Michi

View raw message