cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@cocoon.apache.org
Subject [Cocoon Wiki] Updated: GT2003GianugoMatthewDavid
Date Thu, 20 May 2004 13:47:16 GMT
   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)
+
+
+

Mime
View raw message