Michael Hartle wrote:
>
> Hello all,
>
> while looking for previous thoughts on combining Cocoon2 with WebDAV, I
> luckily stumbled about this post from some time ago. I want to combine
> Documentum, Cocoon2 and OpenOffice as a flexible
> CMS/collaboration/portal solution due to some promising results
> regarding OpenOffice and WebDAV. BTW, once you know you have to activate
> the OpenOffice load/save dialogs somewhere in the Options (thanks to
> Jörg Heilig from Sun), loading/saving over WebDAV really works
> beautifully there.
>
> <sigh>While MS developed filesystem namespaces to allow stuff like
> virtual harddrives and the like for Win32, they ruined this wonderful
> idea later on, for example by providing and using standard File
> Open/Save dialogs that cannot use anything virtual properly...</sigh>
>
> I am looking for a way to perfectly (or better elegantly ?) integrate
> WebDAV into Cocoon2, being able to provide virtual documents for editing
> and retrieve the changes made to those virtual documents; as
> OpenOffice/StarOffice6.0 saves zip archives containing XML files, this
> practically screams for using Cocoon2 ;)
Ok, let me jump into this since I already spent lots of brain cycles on
this.
WebDAV is said to be able to turn the web into a "red-write media".
Well, we'll come back on this later.
You want to integrate Cocoon2 and WebDAV in an elegant way. Ok, let's
make an example: let us suppose we want to webdav enable the cocoon web
site (xml.apache.org/cocoon/). Let us assume for a moment that Cocoon is
stable and fast enough to enable this on our site and it manages this
URI mount.
The most important piece in the sitemap that takes care of this is the
following:
<map:match pattern="**/*.html">
<map:aggregate element="site">
<map:part src="cocoon:/{1}/book-{1}/{2}.xml"/>
<map:part src="cocoon:/body-{1}/{2}.xml"/>
</map:aggregate>
<map:transform src="stylesheets/site2xhtml.xsl">
<map:parameter name="use-request-parameters" value="true"/>
<map:parameter name="header"
value="{1}/graphics/{2}-header.jpg"/>
</map:transform>
<map:serialize/>
</map:match>
Now, let's look at this from the WebDAV perspective: what do we want to
achieve with that? well, assuming that SoC needs to remain in place, we
want editors to be able to change the "content" of that page, graphic
designers to be able to change the "style" of that page.
Imagine you have something like a webdav enabled editor: you access the
the page, you edit it and you PUT it back on that URI.
Now what? XSLT is *NOT* (in general) reversible. Not even talking about
aggregation, namespace reaction, dynamic XML expansion and so on. There
is algorithmically no way that you can achive that.
Think about possible solutions for this problem and you'll end up in a
nightmare of configurations, tricks, impositions and practices and
everything because you want to go this way.
Obvious, you might say, webdav was not created to deal with dynamic
stuff.
Well, guess what: there is almost *NOTHING* static (in the old-days web
sense) in Cocoon, nor nothing in the HTTP spec that tells you that a URI
space should be mapped to static resources and served AS-IS.
WebDAV is nothing different from FTP, from that point of view. It's
FTP-over-HTTP with strings attached: it has *NOTHING* to do with web
publishing unless consider the web server a new way of doing FTP, thus
making public a collection of files.
This said, I can say that I think WebDAV is great because it does
everything that FTP was doing (and HTTP was not!), but it does so in a
much web-oriented way (allowing easily SSL encryption and all those nice
things) and adds important things like versioning, locking and all that
(besides, it's the first IETF standard to use XML namespaces and one
should love it just for that!)
So, the quesiton is: do Cocoon and WebDAV match?
Let's look it from another perspective: content writers, also called
"editors".
Content editors use M$ Word and save files on a folder. Anything more
complex than this mixes concerns, thus is percieved as overwelming and
"difficult".
Sorry, no way around this. This is the way the world works (with few
exceptions) so we must enable them or we are lost with a great
infrastructure of semantically marked-up content and *NOBODY* who writes
the damn content.
Anyway, M$ office added "FTP folders" first, then IE added webdav
enabled "web folders" to the windows explorer. MacOSX is also adding
webdav support directly in the finder. It's easy to presume that other
file managers (Nautilus, Konqueror) are already planning to add these
functionalities (if they don't do so already, I'm not a linux guy).
Ok, so we can presume the editors have a simple and standard interface
for "authoring" content thru WebDAV. The editing tool will still be a
problem (wait for my next RT for that) but if we define the contract
thru WebDAV, we can, at least, separate the concerns and work parallely.
- o -
So, the question is where do we add WebDAV capabilities?
I see two possible solutions: direct and indirect. Direct means passing
thru cocoon, indirect means bypassing Cocoon.
1) indirect: this is something that you can do even today with no need
to write a single line of software. Create a virtual host (or another
mount point, or another port on the server) that connects simply to the
content documents that you want to serve.
You can use mod_dav for that or the Tomcat webdav servlet or Slide: on
one location you publish the resource (and you make it public), on
another you author it (and protecting it with passwords or SSL crypto or
even client side certification).
This requires a few things:
a) you setup your cocoon enviornment knowing that this will be done
b) you protect your resource with .htaccess files or equivalent
(UID/GID, tomcat realms, whatever you want).
c) if you store your files in some other repository, you write some
connector between the webdav interface and your storage system.
Tamino already does this, for example. In fact, it uses an extension to
Tomcat's WebDAV servlet to webdav-enable their XML server.
As far as dbXML gets under Apache, I plan to work on something
equivalent for this database as well, hopefully getting it integrated
with the database core in order to obtain stuff like versioning and
resource metadata directly from the database.
One feature I'd love, would be to cover some webdav folders with
automatic validation: for example, triggering an error if you are saving
a docbook XML into a folder where XSLT is expected, or viceversa. There
is no specific HTTP error message for that, but some 4xx with specific
messaging would allow most webdav clients to report the error in a
significant way and would allow us to guarantee a solidity of our
internal contracts. [consider this a tool against the stupidity of
editors who save documents where they want and not where they are said
to]
Anyway, future Apache projecs aside, all these are examples of indirect
use of WebDAV to make it possible to edit a cocoon-powered web site in
an effective way.
2) direct: this requires webdav support built into Cocoon.
http://host/path/file.content
and we obtain the content view of the resource.
Now, suppose we add some semantics in the sitemap in order to support
webdav operations. We could use actions or even generators, matched
after webdav http actions that might allow people to author directly
thru Cocoon.
But what would we gain with this approach? I see two possible things:
a) keep the URI the same (so avoid using a bunch of mod_mime_magic and
mod_rewrite rules to allow the URI space to be the same between Cocoon
and it's webdav parallel. Also makes it easier for people to remember
what and where to save (or, at least, to give the URI-space designers
total control simply using the sitemap).
b) create webdav applications.
Now, this is an entirely new concept but potentially explosive: we
normally talk about "publishing" when the GET action is mainly in use,
then "web application" when both GET and POST are extensively used. Now
I coin the term "webdav applications" for particular web applications
when the full range of webdav http headers is used by the user agent.
The best example I can imagine of such "webdav applications" is a
"publishing workflow management system", but I'm sure there could be
tons of it (as it is for webapps).
So, since webdav is simply an extension of HTTP, I believe that when
Cocoon will be able to easily deal with webapps (when the flowmap will
be in place), we obtain (almost for free) the ability to implement
"webdav apps" as well and it might really turn out to make Cocoon a
kick-ass digital publishing solution.
This has also the advantage of not requiring the data storage systems to
implement webdav directly, but gives cocoon users the ability to
componentize their webdav app as they would with their pages or for
their webapps.
Gosh, it would really kick ass, don't you think? and once the flowmap is
in place, all needed funtionality it's probably going to be a few
webdav-capable cocoon components away.
Well, anyway, something is for sure: the future of web authoring is
webdav and Cocoon must follow that trend or won't be used in places
where it would really kick ass.
Hope this helps.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
