Cocoon, Webdav and more...

with Matthew Langham, Gianugo Rebellino and David Nuescheler (from Day Software - the company Roy Fielding is working for)

Raw notes taken collaboratively during the talk by Stefano Mazzocchi, Bertrand Delacrétaz, Rogier Peters, Steven Noels, Jeremy Quinn.

Matthew starts.

WebDAV history

How did WebDAV start?

WebDAV mission

Multiple people can work together, on different platforms Simple, extendible, uses HTTP infrastructure

Can be based on Databases, File System, CVS, etc. Many tools support WebDAV. Moving from a WebDAV server to another is fairly easy.

WebDAV functionality

Diagram: HTTP at the base, WebDAV on top, DeltaV, ACL and DASL on top of WebDAV.

WebDAV servers

WebDAV clients

Can access WebDAV servers as file folders, file browser integration.

Cocoon and Webdav (Gianugo kicks in)

(yet another) dynamic duo? Cocoon and WebDAV!

WebDAV is an HTTP protocol with XML payload. Cocoon is a perfect candidate for a WebDAV interoperation.

Technical aspects

Good points

Weak points

So basically WebDAV is good for simple stuff but can get in the way for more complex requirements, specially if you need the advanced features (versioning, search, access control).

What can we do with WebDAV in Cocoon

Let's go through a propfind request

A propfind on a collection returns an XML multistatus response with properties for every document in the collection - can be processed by an XSLT transform easily.

WebDAV as a client

SourcePropsWritingTransformer: enables write access to resource properties.

DASLTransformer: performs DASL queries (sort of a SQLTransformer for a WebDAV DASL-enabled repository)

WebDAV as a server

If we want to build a server with WebDAV we don't need any particular component (well, almost... because generating all the specific WebDAV stuff is not so easy, so having special component might be helpful).

The WebDAV block contains a dir2propfind.xsl to ease property handling. It converts a DirectoryGenerator output into a PROPFIND response.

We need user feedback to understand what you want to do with a Cocoon enabled WebDAV server.

WebDAV as a proxy

WebDAV architectures that could be used

Traditional

Problem: no actual use of WebDAV protocol if WebDAV is used only internally, doesn't bring any benefits?

Gianugo's proposal

Using cocoon as a virtual WebDAV server brings many benefits: aggregation, "interception" of WebDAV operations, etc.

Dream list

Transactions is a hard problem to solve - hard for Cocoon to find out exaclty what happened on the back-end and manage failures correctly.

Catacomb is an apache httpd (mod_dav) extension which does DASL but can only store data in MySQL.

Pro-netics (Ricardo Rocha) is working to enhance Catacomb, supporting ODBC as the backend.

JSR 170

http://www.jcp.org/jsr/detail/170.jsp

The specification lead of JSR 170, working at Day

Use case: the MyBank website. The bank uses a CMS for the website, another CMS for their intranet and they have to duplicate a bunch of stuff.

The problem with proprietary CMSes is that your stuff gets shielded behind one out of 200+ APIs related to CMS.

David shows some code snippets of different API that are used to connect to the various proprietary repositories.

Aim: One API for all content repositories - architecture, data source and protocol neutral.

Content is Data ++ Content is managed Data/Information

JSR has two levels of compliancy. This is similar to yesterday's talk, see GT2003HackathonJsr170

Level 1 is simple to implement for vendors. Scope is:

Level 2 (extensive functionality)

Lots of overlap between webdav and JSR 170, a good parallel is HTTP and Servlet API: one is the protocol, another thing is the API.

He shows one of Gianugo's slides and adds JSR 170 (also based on yesterday's talk about how to build a CMS on top of cocoon)

backend <--> repository <--> frontend
                ^
                |
                V
             sideend

Current Situation

final thoughts

GT2003GianugoMatthewDavid (last edited 2009-09-20 23:40:29 by localhost)