cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Sat, 03 Nov 2001 22:49:14 GMT
Per Kreipke wrote:

 >>Sure, but not only that: probably you don't want your sitemap,
 >>components and the like to be accessible from WebDAV: I for sure
 >>wouldn't, for security reasons to say the least.
 > Well, I'm not so sure (could be my ignorance!). I suppose that 
 > solve concurrent access problems but here's what I'm curious to try. 
 > of locking an entire site map or sub-sitemap to add a generator or 
 > to a particular resource, what if I could lock and update just a 
 > element top most <map:xxx> element or sub element.

  > E.g. in the large sitemap included with the distribution, suppose I
have 3
  > site developers who need to manage a portion of a live site, it'd be
  > if you could simply lock a portion of the file
  > /foo/sitemap.xmap//map:serializers[@name='wap']

Looks like you're talking of a WebDAV locking at the *element* level in
an arbitrary XML document. Cool for sure, how feasible? :)

The next consideration come from the good old software engineering
motto: are we doing the right thing? are we doing the thing right? I'm
scared at the idea of 3 different people that need to play around
continuously with the sitemap so much to require a "low level" locking
(speaking in database terms): I think I still have to see a site that
needs such a level of intervention at the *sitemap* level, and I tend to
think that you shouldn't edit your sitemap much more times than you 
would be editing your httpd.conf. The only scenario where I can see such 
a need is in a mass virtual hosting environment, but again I'm not that 
sure that Cocoon would fit in such an environment.

 > What does the 'folder' metaphor looks like when you drill into an XML
 > representation of Michael's headline/article store (or something more
 > complicated)? What's the most granular item? What's the content type 
of each
 > 'file' (needed to map it to an application, or do they all have file
 > extensions)? What if that 'file' is itself an aggregation? Sorry, I still
 > don't get this part but I'm eager to! :-)

I'm afraid I can't help you here but saying that overall managing a 
write-enabled Cocoon in a general would be a PITA :) This is way I'm 
more and more convinced that the CMS concerns should be handled outside 
of Cocoon (maybe *using* Cocoon to build a CMS).

 >>But this is the easy part! Take mod_dav, slide or the WebDAV servlet and
 >>you're ready to go, you don't need any specific Cocoon support. Just
 >>WebDAV-enable your cocoon webapp and try out Pollo
 >>( as a starting point. It shouldn't be
 >>difficult to integrate Pollo into, say, Netbeans, et voila' you have a
 >>Cocoon IDE ready for your marketing guys ;)
 > Ok. I'm with you but I think for large sites, more granular 
management could be needed.

Again: possibly not at the presentation level. Careful sitemap design 
and a powerful CMS as a backend should help in dealing with those issues 
(meaning that the day to day work should be done in the CMS).

 >>Please define what you exactly mean for "end user" and "developer".
 >>Where are content developers (i.e. writers) placed in your setup? I
 >>understand that you're labeling them as "end users", and I don't agree
 >>completely with you on that.
 > You're right. I mean 'content developers'. I basically mean the guy 
at the
 > browser, not the guy sitting with XMLSpy working on the sitemap.

OK, let's agree on something. I propose the following names (Stefano, 
bear with me: I know this is not exactly what we have in mind, but it's 
just to clarify my point):

1. End users: the ones that sit in front of a client and enjoy the 
services and contents from the sites (me reading Slashdot)
2. Content developers: the ones that write the content of the site (me 
writing a news for Slashdot);
3. Editors: the ones that decide what content is suitable for 
publication (CmdrTaco that approves my news and publishes it in Slashdot);
4. Webmasters: the ones that decide the layout of the site and manage 
the sitemap and the web server configuration files;
5. Web developers: the ones that write the software components 
(assembled  and deployed later on by webmasters).

My point is that only 2) and 3) might benefit from a Cocoon-enabled 
WebDAV. 4) might use the existing tools (even though having integrated 
locks and versioning might help). 5) in general should not have any 
access to the production site and hey might well work on staging 

 >>Web forms suck big time. This is the main concern: if you are a writer
 >>and need to edit real world documents you can't stand the textarea
 > That's true. But there are lots of plug-ins for enhanced text areas.

Which suck big time too ;) If you're a writer you want your tool. If I'm 
a sysadm I can't do system administration using a web browser: I want my 
shell. If I'm a programmer I can't code using textareas: I want my 
editors (no, this does not include Emacs ;P). If I'm a writer, I want my 
word processor. It's just a matter of the right tool for the right job.

 > Also, I think you're getting very document centric. I think of Cocoon 
as a
 > complete XML engine, it's not all text articles.

Gotcha. You're right, but probably in that case you wouldn't need WebDAV.

 > Ah. If you only had element by element locking and validation ;-)

And versioning, and transcations, and an Open Source JVM, and real 
threads in Linux, and Bill Gates working in a salt mine... ;-)


Gianugo Rabellino

To unsubscribe, e-mail:
For additional commands, email:

View raw message