cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <>
Subject RE: [RT] Integrating Cocoon with WebDAV
Date Mon, 05 Nov 2001 16:48:45 GMT
>   > 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
> slick
>   > 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.

Uh oh. It wouldn't? Before I try it then, could you enlighten me why I
wouldn't want to do this :-)

Also, I was thinking about altering the sitemap programmatically too,
another reason I wanted to do element level locking.

>  > 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).

Exactly :-)

>  >>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
> environments.

Well, I don't agree with your comments about 4&5, that is,  only they manage
site structure. I think that in a true 2 way web, the distinction about what
constitutes site structure and content and software becomes quite malleable
and consequently who should be allowed to edit changes too.

Think of the DMOZ hierarchy, I think that all editors (#3) have sitemap
privileges (#4) [or at least, that the role of adding new directories isn't
done by editing config files]. Another example: end-users who place Tripod's
Gears (e.g. polls, threads, news, etc) on their pages are

>  >>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
>  >>limitations.
>  >>
>  >
>  > 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.

I agree. I didn't say that text areas/plug ins should be 'content ignorant',
in fact I think that plug-ins are _by definition_ such adaptors, e.g. each
of those roles you mention should have its own plug-in [IDE plug-in
{Forte?}, word processor {isn't Word going to run over the web soon},
command shell {see VNC computing- }]

>  > 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.

Why's that? I still want element level locking for programmatic access.

>  > 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... ;-)

Hey, J2EE has a great start on some of this. I figured that a J2EE-like
interface based or XML based set of contract for the pipeline that Stefano
proposed would be just the thing.


P.s. Not the way settlement talks are going ;-)

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

View raw message