You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by do...@cocoon.apache.org on 2004/05/20 15:47:16 UTC
[Cocoon Wiki] Updated: GT2003GianugoMatthewDavid
Date: 2004-05-20T06:47:16
Editor: 212.254.251.89 <>
Wiki: Cocoon Wiki
Page: GT2003GianugoMatthewDavid
URL: http://wiki.apache.org/cocoon/GT2003GianugoMatthewDavid
no comment
Change Log:
------------------------------------------------------------------------------
@@ -1,192 +1,193 @@
-= 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?
-
- * Tim Berners-Lee meant www to be a writeable medium.
- * NCSA Mosaic pushed publish/browse to the foreground, writing to the background
- * Navigator Gold had an editor
-=== WebDAV mission ===
-
- * The World is a Folder
- * Edit and save metadata
-
-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 ===
- * Basic functions
- * Locking, metadata, namespace
- * DeltaV
- * auto-versioning, checkout/checkin
- * ACL
- * Access control
- * DASL
- * Searching
-
-Diagram: HTTP at the base, WebDAV on top, DeltaV, ACL and DASL on top of WebDAV.
-=== WebDAV servers ===
- * Tamino
- * Apache 2.0
- * Catacomb
- * Slide
- * Others damn he's fast
-=== WebDAV clients ===
- * XmlSpy
- * Xmetal
- * Microsoft
- * Office
- * Explorer
- * Adobe
- * Photoshop
- * GoLive
- * MacOSX Finder
-
-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 ===
- * WebDAV is a networked file system with strong point on metadata
- * Extensible metadata exposed as Namespaced XML
- * Revamped http + xml protocol, WebDAV is just an extension, you can still use HTTP only.
- * Your WebDAV server is still an HTTP server
- * Rich semantics for metadata. Until now we stored documents in RDBMs with metadata
- * Easy to use for easy tasks
- * Ubiquitous and cross platform (vendor independent)
-=== Weak points ===
- * http is not used as a pure transport layer.
- * No clear encapsulation.
- * Some information is in payload, some information is in request headers.
- * no real support for "real" XML metadata
- * it's an implementation issue
- * if you put an XML snippet as a metadata, it's just stored as a blob
- * you can't do xpath queries on it
- * difficult to use for difficult task
- * Cocoon might shield some of this complexity, but might not go too far and you have to do the rest
- * Like moving directories around
- * specs are somehow unclear, too many extensions in draft phase (DeltaV, DASL, DAV ACT).
-
-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 ==
- * Support in the block
- * you can use it as a client (stable, used in production with no issues)
- * you can make a WebDAV server with Cocoon (needs work), this is probably the most promising way.
- * client is stable
- * server still needs work
-
- * Proxy for a back-end WebDAV server, forward requests with optional processing
-=== 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 ===
- * WebDAV Source:
- * Avalon source implementing all subinterfaces (Traversable, Modifiable, Inspectable)
- * You can store a bunch of stuff (stylesheet, sitemap, xsl, xml, assets) inside your WebDAV server.
-=== 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 ===
- * Why use a proxy?
- * usecase is to implement missing features on backend WebDAV server (for example DASL)
- * Problem is, proxying is done at the Servlet API level, inefficient, lots of cloning of objects.
- * Add virtual resources (a PDF view or resized images)
- * Send email or events when something happens (storage, attribute change etc)
- * Provide easy and effective authentication
- * Mangle properties using simple Explorer-like file managers (a simple way to connect and edit the repository and its properties ... no special needs for clients)
- * Dragging a file on the client could change a property of the WebDAV file instead of actually moving it (IIUC?)
-== WebDAV architectures that could be used ==
-=== Traditional ===
- * dav server
- * admin app
- * web interface to the admin app
- * delivery app -> client
-Problem: no actual use of WebDAV protocol if WebDAV is used only internally, doesn't bring any benefits?
-=== Gianugo's proposal ===
- * Put the dav server in the Cocoon core
- * All the different clients are accessing the webdav server directly
- * Then you build the delivery app
- * Problem: do you really want your client to connect directly to your DAV server
- * Solution: cocoon between WebDAV server and client
- * Use WebDAV, DBs, LDAP as backend, accessed over WebDAV
-
-Using cocoon as a virtual WebDAV server brings many benefits: aggregation, "interception" of WebDAV operations, etc.
-=== Dream list ===
- * having much easier access to the request body
- * Is a different Environment enough? Need new sitemap semantics?
- * WebDAV proxying needs transation supports (for example, in order to implement DASL) . Failure needs to be reported, because inconsistencies might pop in.
-
-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:
- * Access
- * Read/Write
- * Support hierarchy operations (copy/move/link)
- * XML serialization
- * Search
- * Content typing
-
-Level 2 (extensive functionality)
- * Versioning
- * Locking
- * Observation
- * Transations
- * Access control
-
-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 ===
- * going thru "community review"
- * the open source reference implamentation is inside Jakarta Slide (inside the CVS as a proposal)
- * the current RI is webdav-enabled already
-=== final thoughts ===
- * webdav is an excellent transport layer for JSR 170 -> RI
- * JSR 170 can be used as a generic client API to talk to a granular (property) level to a WEbdav server (and friends)
-
-
-
+= 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?
+
+ * Tim Berners-Lee meant www to be a writeable medium.
+ * NCSA Mosaic pushed publish/browse to the foreground, writing to the background
+ * Navigator Gold had an editor
+=== WebDAV mission ===
+
+ * The World is a Folder
+ * Edit and save metadata
+
+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 ===
+ * Basic functions
+ * Locking, metadata, namespace
+ * DeltaV
+ * auto-versioning, checkout/checkin
+ * ACL
+ * Access control
+ * DASL
+ * Searching
+
+Diagram: HTTP at the base, WebDAV on top, DeltaV, ACL and DASL on top of WebDAV.
+=== WebDAV servers ===
+ * Tamino
+ * Apache 2.0
+ * Catacomb
+ * Slide
+ * Others damn he's fast
+=== WebDAV clients ===
+ * XmlSpy
+ * Xmetal
+ * Microsoft
+ * Office
+ * Explorer
+ * Adobe
+ * Photoshop
+ * GoLive
+ * MacOSX Finder
+
+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 ===
+ * WebDAV is a networked file system with strong point on metadata
+ * Extensible metadata exposed as Namespaced XML
+ * Revamped http + xml protocol, WebDAV is just an extension, you can still use HTTP only.
+ * Your WebDAV server is still an HTTP server
+ * Rich semantics for metadata. Until now we stored documents in RDBMs with metadata
+ * Easy to use for easy tasks
+ * Ubiquitous and cross platform (vendor independent)
+=== Weak points ===
+ * http is not used as a pure transport layer.
+ * No clear encapsulation.
+ * Some information is in payload, some information is in request headers.
+ * no real support for "real" XML metadata
+ * it's an implementation issue
+ * if you put an XML snippet as a metadata, it's just stored as a blob
+ * you can't do xpath queries on it
+ * difficult to use for difficult task
+ * Cocoon might shield some of this complexity, but might not go too far and you have to do the rest
+ * Like moving directories around
+ * specs are somehow unclear, too many extensions in draft phase (DeltaV, DASL, DAV ACT).
+
+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 ==
+ * Support in the block
+ * you can use it as a client (stable, used in production with no issues)
+ * you can make a WebDAV server with Cocoon (needs work), this is probably the most promising way.
+ * client is stable
+ * server still needs work
+
+ * Proxy for a back-end WebDAV server, forward requests with optional processing
+=== 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 ===
+ * WebDAV Source:
+ * Avalon source implementing all subinterfaces (Traversable, Modifiable, Inspectable)
+ * You can store a bunch of stuff (stylesheet, sitemap, xsl, xml, assets) inside your WebDAV server.
+=== 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 ===
+ * Why use a proxy?
+ * usecase is to implement missing features on backend WebDAV server (for example DASL)
+ * Problem is, proxying is done at the Servlet API level, inefficient, lots of cloning of objects.
+ * Add virtual resources (a PDF view or resized images)
+ * Send email or events when something happens (storage, attribute change etc)
+ * Provide easy and effective authentication
+ * Mangle properties using simple Explorer-like file managers (a simple way to connect and edit the repository and its properties ... no special needs for clients)
+ * Dragging a file on the client could change a property of the WebDAV file instead of actually moving it (IIUC?)
+== WebDAV architectures that could be used ==
+=== Traditional ===
+ * dav server
+ * admin app
+ * web interface to the admin app
+ * delivery app -> client
+Problem: no actual use of WebDAV protocol if WebDAV is used only internally, doesn't bring any benefits?
+=== Gianugo's proposal ===
+ * Put the dav server in the Cocoon core
+ * All the different clients are accessing the webdav server directly
+ * Then you build the delivery app
+ * Problem: do you really want your client to connect directly to your DAV server
+ * Solution: cocoon between WebDAV server and client
+ * Use WebDAV, DBs, LDAP as backend, accessed over WebDAV
+
+Using cocoon as a virtual WebDAV server brings many benefits: aggregation, "interception" of WebDAV operations, etc.
+=== Dream list ===
+ * having much easier access to the request body
+ * Is a different Environment enough? Need new sitemap semantics?
+ * WebDAV proxying needs transation supports (for example, in order to implement DASL) . Failure needs to be reported, because inconsistencies might pop in.
+
+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]
+public review: [http://jcp.org/aboutJava/communityprocess/review/jsr170/index.html]
+
+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:
+ * Access
+ * Read/Write
+ * Support hierarchy operations (copy/move/link)
+ * XML serialization
+ * Search
+ * Content typing
+
+Level 2 (extensive functionality)
+ * Versioning
+ * Locking
+ * Observation
+ * Transations
+ * Access control
+
+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 ===
+ * going thru "community review"
+ * the open source reference implamentation is inside Jakarta Slide (inside the CVS as a proposal)
+ * the current RI is webdav-enabled already
+=== final thoughts ===
+ * webdav is an excellent transport layer for JSR 170 -> RI
+ * JSR 170 can be used as a generic client API to talk to a granular (property) level to a WEbdav server (and friends)
+
+
+