cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <...@onclave.com>
Subject RE: [RT] Integrating Cocoon with WebDAV
Date Mon, 05 Nov 2001 17:23:25 GMT
> > > Again, I think WebDAV access through Cocoon is more than worth the
> > > effort.
> >
> > Definitely worth having, not clear how :-)
>
> Uh, what a thread :)
>
> Ok, let's try to summarize a little.
>
> This is what I believe is a good chain for publishing:
>
>  user agent <- publishing <- store <- CMS <- edit agent

I agree with Gianugo that the CMS should hide the store:

user agent <- publishing <- CMS <- edit agent
                              |
                            store

But I would definitely expect to allow this for performance or simplicity:

user agent <- publishing <- CMS <- edit agent
                  ^           |
                  |-------  store

Cocoon shouldn't require a CMS but should use one if it has it [you say so
yourself later].

> which is a native XML DB. IMO, it lacks a few features to turn it into
> such a storage system (most notably, versioning, locking and a few other
> things that things like CVS has), but it's a great place to start and a
> great way for the publishing system to have access to the content (thru
> XQL or the like).

One thing I'm not thrilled about with dbXML is that it's document centric
[my opinion may be out of date, I'm not sure], it's hard to query across XML
documents.

>  user agent <-(http)- cocoon <-(xql)- xindice <-(?)- ? <-(webdav)- ?
> which leaves three big question marks.
> The unknown contract will probably be filled by the xindice guys (XMLDB
> API being the probably candidate, but maybe a JSR would add that
> functionality into JDBC4, I don't know at this point, but I'm confident
> that something will come out as soon as the xindice people (with us)
> tackle the problem in detail).

Ok, so given that we eventually define all the contracts, why do we need to
choose the implementations? I think that, in the J2EE vein, being able to
choose my own implementation for
'standard services' is a great one.

Isn't it ok to define the missing contract but leave the implementations as
'?'.

>  1) CMS because Cocoon shouldn't implement CMS stuff but should simply
> "use it". Things like user management, locking, revisioning, metadata,
> scheduling and all that should be a layer built around the storage. The
> contract between CMS and cocoon being some API or some avalon behavioral
> services.

Great!

> At the same time, content editors don't give a shit about "where"
> resources are located and I disagree vehemently with Gianugo when he
> says that you have to give them the harddisk methaphor otherwise they
> are screwed.
>
> Well, they would be anyway: in fact, when they approach an editing
> system, they don't ask the question "where", but "what". The translation
> between "what content to modify" and "where to save it", mixes concerns.

Based on some exerience, I agree with you Stefano. One example, newspaper
editors deal with departments, 'beats', teams, campaigns, what have you,
many of which cross over. Their organization certainly doesn't have to be
hierarchical. And newspaper writers are very accustomed to filing stories
from far away without a 'desktop' metaphor at all. In fact, they're so
_extremely_ time sensitive (down to beating other competing outlets by
seconds with a news story), they rarely use cumbersome, slow, generic word
processors, they use highly customized apps.


> How so? A XUL-powered mozilla IDE that integrates skeleton-based
> in-place editing capabilities.

I don't understand. Why not just say 'XUL for in-place editing'? Why does it
have to be mozilla based?

> So, should webdav be integrated into Cocoon? well, at this point, it's
> early to tell and it depends on the shape that the CMS part will take.
>
> One thing in my mind is for sure: Cocoon shouldn't become a CMS, but
> might well adapt the CMS API with the XUL-powered solution and, in that
> case, it might require some WebDAV capabilities of some sort.

Ah, there it is without any choices about what CMS or editor I have to tie
myself to :-)

Per


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message