You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by Edgar Poce <ed...@gmail.com> on 2006/08/26 01:29:01 UTC
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
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
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/27/06, Edgar Poce <ed...@gmail.com> 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 with potential for
outlining the long term design goals of Jackrabbit.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Christophe Lombart <ch...@gmail.com>.
On 8/27/06, Jukka Zitting <ju...@gmail.com> wrote:
>
> 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.
We can review this kind of design. Separates server interface gives
you the possibility to register and than use multiple repositories
(based on different API : JCR, OJB, ...).
You can also create your own Service impl to register a proprietary repository
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/28/06, Edgar Poce <ed...@gmail.com> wrote:
> On 8/27/06, Jukka Zitting <ju...@gmail.com> 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, I had just understood it's a MPL derivative. I hate when
companies do that, modify OS licenses in subtle ways. The extra
constraints are related just to GUI applications, so they shouldn't
matter for a repository implementation as long as any client
applications use it through the standard API. In any case it's not
something that could be brought to Apache.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
On 8/27/06, Jukka Zitting <ju...@gmail.com> 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 addition to the other notice obligations, all copies
of the Covered Code in Executable and Source Code form distributed
must, as a form of attribution of the original author, include on each
user interface screen (i) the " Alfresco Community" logo, (ii) the
vendor disclaimer "Supplied free of charge with no support, no
certification, no maintenance, no warranty and no indemnity by
Alfresco Software, Inc or its certified partners" ...
br,
edgar
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/27/06, Edgar Poce <ed...@gmail.com> wrote:
> 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?
I think the main point is to allow the use of different backend stores
for the Graffito content. So even though the Graffito object model is
somewhat fixed (see the CmsObject hierarchy), the idea is to allow the
object model to be transparently saved on a combination of different
backend stores based on custom configuration.
I'm unfortunately not yet familiar enough with Graffito to comment on
your other questions and alternatives. Perhaps others can step in and
enlighten us.
> 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?
+1 I'd very much like to see simple JCR-over-filesystem,
JCR-over-webdav, and JCR-in-memory repository implementations based on
some simple repository framework. As you mentioned, Jackrabbit core is
probably too monolithic to do that, so an alternative approach like
the early drafts I did for jcr-ext or the current JCR SPI effort could
be a good starting point. I'm not too familiar with the Alfresco
codebase, but that's also a possible alternative to look at.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
On 9/1/06, Edgar Poce <ed...@gmail.com> wrote:
>in the use case described
> at http://mail-archives.apache.org/mod_mbox/portals-jetspeed-user/200607.mbox/browser,
the link should be
http://www.nabble.com/Migrating-portlet-preferences-stored-in-a-database-from-test-to-production-tf2020763.html#a5597352
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
On 9/2/06, Christophe Lombart <ch...@gmail.com> wrote:
> What is jcr portlets, I think it is JCR service or something like that no ?
> eg. portlet JCR admin browser
yes, e.g. most of the portlets enumerated at the third item of my
previous post. Portlets built on top of the JCR api.
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Christophe Lombart <ch...@gmail.com>.
On 9/2/06, Edgar Poce <ed...@gmail.com> wrote:
>
> There's only one drawback that comes to my mind: since the content
> will be touched from many places all the constraints and security
> policies should be handled at the repository level in order to
> guarantee data integrity. That would probably lead to extend the
> repository constraint functionality through decoration or whatever
> strategy.
>
> WDYT? has it any sense?.
of course
Anyway, I'm working on the wysiwyg jcr
> portlet to show how a porlet "content" mode would look, I'll share it
> asap.
>
ok
>
> -----------------------
> gft modules
> -----------------------
> gft services
> -------------- -----------------------
> jcr portlets gft persistence service
> ----------------------------------------
> webdav |-> jcr | rdbms | fs | webdav
> cifs |
> nfs |
> ldap |
> etc.
>
What is jcr portlets, I think it is JCR service or something like that no ?
eg. portlet JCR admin browser -> jcr service -> One of the referenced
JCR server.
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
Hi,
Please bear with me and let me know if I'm spamming the list, I told
I'm new to CMSs. I gave the thing a second thought and I think that
both approaches can play quite nicely. A part of the CMS can act
directly at the content level (jcr portlets and jcr network
interfaces) and another part work at a higher level of abstraction
(GFT services) providing a subset of the features in order to ease the
development and integrating nicely with OO designs.This way the GFT
api would maintain its simplicity and leverage the jcr features and
some extensions (e.g. an audit trail at the content level) that act at
content level.
There's only one drawback that comes to my mind: since the content
will be touched from many places all the constraints and security
policies should be handled at the repository level in order to
guarantee data integrity. That would probably lead to extend the
repository constraint functionality through decoration or whatever
strategy.
WDYT? has it any sense?. Anyway, I'm working on the wysiwyg jcr
portlet to show how a porlet "content" mode would look, I'll share it
asap.
br,
edgar
-----------------------
gft modules
-----------------------
gft services
-------------- -----------------------
jcr portlets gft persistence service
----------------------------------------
webdav |-> jcr | rdbms | fs | webdav
cifs |
nfs |
ldap |
etc.
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
On 9/1/06, Christophe Lombart <ch...@gmail.com> wrote:
> > I agree with you that GFT api is much simpler from a developer
> > perspective, however it's not as feature rich as jcr, and I'd prefer
> > the CMS to focus on providing generic features for any content rather
> > than providing less features for a fixed set of types.
> >
> I think it is possible to have generic features. The workflow will be
> a good exemple. It will be possible to define a specific workflow
> process for any kind of content.
> Please, give us some examples. what kind of generic features are you
> thinking about ?
>
sorry I wasn't clear, I had no specific feature in mind, I meant
generic because it would work on top of a standard api, against
content generated through the CMS or through other apps that need no
knowledge of a custom api.
br,
edgar
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Christophe Lombart <ch...@gmail.com>.
> I agree with you that GFT api is much simpler from a developer
> perspective, however it's not as feature rich as jcr, and I'd prefer
> the CMS to focus on providing generic features for any content rather
> than providing less features for a fixed set of types.
>
I think it is possible to have generic features. The workflow will be
a good exemple. It will be possible to define a specific workflow
process for any kind of content.
Please, give us some examples. what kind of generic features are you
thinking about ?
> > 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.
> >
>
> Well, it doesn't seem so easy on top of jcr. If that's the main goal
> of graffito it would probably make sense to use a custom api.
>
The OCM tools will help us to add a strong JCR support from our high
level services. Unfortunatly this is not yet implemented.
> sure, I could make a prototype. From the list bellow, where I describe
> a few items I'd love to see in graffito/j2, I'd like to make a
> prototype of the second item. Is it the kind of prototype you had in
> mind?
>
Why not - there are some interesting ideas and nice features.
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
Hi,
On 8/31/06, Christophe Lombart <ch...@gmail.com> 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
> Graffito API is more simple for a business developer. I'm just curious
> to know you point of view on that.
>
I agree with you, personally I don't like the verbosity caused by
checked exceptions thrown by almost every method in jcr. I don't think
it's a good practice to use checked exceptions everywhere. The jcr
client code usually looks pretty ugly even if checked exceptions are
wrapped in runtime exceptions and caught at the top of the stack. IMHO
jcr lacks a runtime exception for the common "in case another error
occurs" which can be found all over the spec.
I agree with you that GFT api is much simpler from a developer
perspective, however it's not as feature rich as jcr, and I'd prefer
the CMS to focus on providing generic features for any content rather
than providing less features for a fixed set of types.
> 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.
>
Well, it doesn't seem so easy on top of jcr. If that's the main goal
of graffito it would probably make sense to use a custom api.
> 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.
you should :), as I told I'm a newbie in CMSs so any help and feedback
is very much appreciated.
> Why not ot make a
> prototype based on your ideas ?
>
sure, I could make a prototype. From the list bellow, where I describe
a few items I'd love to see in graffito/j2, I'd like to make a
prototype of the second item. Is it the kind of prototype you had in
mind?
I plan to make a wysiwyg portlet that will store the html in an
nt:file node in the repository. The htlm content will be editable
either from the portlet or from webdav thanks to jcr-server contrib in
jackrabbit. And cms specific operations will be performed from the
portlet in edit or content mode (see item 2).
1.
Independently of implementation details I'd like graffito/J2 to
provide a content root for each fragment of type portlet, a place to
put the specific data of a portlet instance in a given page. Something
similar to portlet preferences but with a more powerful api that
allows to manage structured and unstructured data (maybe a jcr node
:), unlike portlet preferences it should be shared among all the users
without the possibility to be user specific. In the use case described
at http://mail-archives.apache.org/mod_mbox/portals-jetspeed-user/200607.mbox/browser,
it would have been very useful. Ideally, when the GFT page manager
implementation is finished, that portlet root node will we a child of
the psml, thus an entire branch of the portal could be versioned
easily.
2.
I'd also like to see a new portlet mode in j2 powered by graffito, a
"content" mode which provides a GUI to manage the root node described
above. e.g. featuring versioning, locking, auditing, content lifecycle
managent (workflow, staging).
I don't know whether it's easy or not to add a new portlet mode in j2,
if it's not very easy I will implement this GUI as an edit mode in the
prototype.
3.
For graffito as an end user product I'd like to have.
- A generic crud portlet.
- A content type modelling portlet for adding new types.
- A template modelling portlet that maps templates to content types.
- A business process modelling portlet that provides out of the box a
set of default workflow actions. Edit, Authorize, Publish, Notify,
etc.
- A generic search portlet.
- An advanced search portlet
- A war portlet. A portlet that keep a copy of every war that was
dropped in j2, thus making the wars manageable by graffito services
(item 2).
br,
edgar
> Anyway, JCR admin tools are interesting and all contribution are
> welcome in this area.
>
> br,
> Christophe
>
>
>
>
> On 8/27/06, Edgar Poce <ed...@gmail.com> wrote:
> > Hi,
> >
> > On 8/27/06, Jukka Zitting <ju...@gmail.com> 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/ - info@yukatan.fi
> > > Software craftsmanship, JCR consulting, and Java development
> > >
> >
>
>
> --
> Best regards,
>
> Christophe
>
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Christophe Lombart <ch...@gmail.com>.
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 <ed...@gmail.com> wrote:
> Hi,
>
> On 8/27/06, Jukka Zitting <ju...@gmail.com> 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/ - info@yukatan.fi
> > Software craftsmanship, JCR consulting, and Java development
> >
>
--
Best regards,
Christophe
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
Hi,
On 8/27/06, Jukka Zitting <ju...@gmail.com> 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/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/27/06, Edgar Poce <ed...@gmail.com> wrote:
> On 8/26/06, Michael Wechner <mi...@wyona.com> 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
> 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.
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.
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.
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.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
Hi Michi,
On 8/26/06, Michael Wechner <mi...@wyona.com> 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,
edgar
> Just my 2 cents
>
> Michi
>
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Michael Wechner <mi...@wyona.com>.
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?
well, it might depend on how much one believes in JCR as one fits all
solution.
Even if JCR is a great thing, it might not fit all purposes and one
might be glad to have an alternative entry point, but I cannot really judge
because I do not Graffito well enough
Just my 2 cents
Michi
>
> 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
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by Edgar Poce <ed...@gmail.com>.
Hi David,
On 8/26/06, David Sean Taylor <da...@bluesunrise.com> 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.
>
Either way it's great your feedback that let me understand GFT
internals and the causes of the decisions that were made. Thanks.
br,
edgar
> 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
> >
> >
>
>
>
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
JCR API.
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
>
>