Your Rating: |
![]() ![]() ![]() ![]() ![]() |
Results: |
![]() ![]() ![]() ![]() ![]() |
91 | rates |
Implemented in 4.2
See WebDAVmodule documentation.
Official Documentation Available
This topic is now covered in WebDAV module.
Introduction
WebDAV protocol allows clients to map resources of compliant server as remote directories, thus greatly simplifying resource update and manipulation.
Evaluate existing implementations, choose the best base for Magnolia WebDAV, estimate effort for full implementation.
Goals
- provide mechanism to access content of various workspaces of Magnolia using
dav
protocol.
WebDAV information sources
- RFC 2518 (WebDAV - HTTP Extensions for Distributed Authoring)
- RFC 3253 (DeltaV - Versioning Extensions to WebDAV)
- RFC 3648 (Ordered Collections Protocol)
- RFC 3744 (Access Control Protocol)
- draft-reschke-webdav-search (WebDAV SEARCH; previously DASL - DAV Searching and Locating)
- draft-ietf-webdav-bind (Binding Extensions to Web Distributed Authoring and Versioning (WebDAV))
Existing WebDAV server implementations
The list below is not complete, only includes implementations considered as possible base for implementing support of webdav in Magnolia.
All implementations below are done as servlets.
- Tomcat webdav support
- Randombits/Confluence webdav plugin
- JackRabbit webdav library
Current Status
Nodes mapping
mgnl:folder
mapped as foldersmgnl:content
mapped as files- For layout and templates workspaces
text
property value is mapped as the content of the file
magnolia view (layout workspace) | jcr | filesystem | FS view |
---|---|---|---|
css | mgnl:folder | folder | css |
.basic | .mgnl:content | .file | basic.css |
..text | ..jcr:property | ..content of the file | .. |
Since we map only one property into the content of the file, rest of the properties are hidden to the filesystem and depend on the node they belong to. This means that deletion of the file, results in deletion of the node and all its properties and sub nodes (MetaData). Creation of file in filesystem results in creation appropriate node in Mangolia workspace (incl. MetaData subnode with some default values).
Problems
Most problems at the moment evolve around the way different programs handle file updates. There are basically 3 different scenarios of how different programs updates files:
- vi style - move original
file.css
tofile.css~
and save updated content in newfile.css
- edit style - delete original
file.css
and save updated content to newfile.css
- eclipse style - just overwrite content of the file without deleting it first
The first two scenarios are most common for simple editors and lead to loss of metadata due to deletion of the file.
The third scenario seems to be preferred one by more complex applications (eclipse, cssedit, scream) and is fine as it preserves the metadata.
While we can, as suggested by some, simply ignore this and state that this is a problem of the editor and the way it handles files, it will cause problems in Magnolia. Also since it is unpredictable I personally do not think we can simply ignore it. If we do, it might lead to situations where parts of the site will not be renderable due to missing MetaData
(e.g. template information) and will require manual corrections.
Of course the situation is similar in case of new content added via webdav, but in this case it is expected that MetaData
will not be set.
At this moment I can see following possible solutions:
- do not allow deletion and moving of the files via webdav - in this case any editors attempting to do so will fail early and will not cause any damage to magnolia data.
- the caveat is that it basically renders useless half of the features for which webdav would be preferred access option
- use configurable set of default
MetaData
(in case of layout workspace, only critical is the template name) - in this case we can set those even for new content- the caveat here is that
MetaData
for edited content will in some cases change without an obvious (to the customer) reason for example in case when they had previously set different template for the content then the one configured in the default settings forMetaData
- the caveat here is that
- change the exported structure of the nodes in repositories we want to expose - the node with
MetaData
should be exposed as folder and the property with data ("text" in case of layout workspace) would be exposed as file in that directory. This way deleting the directory deletes content from the workspace, any changes to the file representingtext
property affect only value of that property (Deleting the file either removes the property or sets it to empty string).- the caveat I see here is that the structure in filesystem will be more complicated to use - having one file per directory might seem cumbersome to some people
Tasks
Task List
Notes:
- according to http://httpd.apache.org/docs/2.0/mod/mod_dav.html most clients support
digest
authentication and basic over ssl. - Common WebDAV issues:
- client specific problems:
- path encoding differs for mac and windows clients
- different sets of acceptable characters
magnolia-module-webdav
is now committed in svn. Editing of the web.xml
is no longer necessary, just build and deploy the module to test it.
To mount the website workspace as webdav share you have to run something along the:
mount -t davfs \ http://localhost:8080/magnoliaAuthor/.webdav/layout \ /media/locdav
Implementation details of considered solutions
Tomcat webdav library
The tomcat webdav support is tight to providing html authoring via webdav and implementation is all based about this fact. There is no clear separation of concerns which would make it difficult trying to reuse this implementation to serve magnolia content.
Randombits/Confluence webdav plugin
The Randombits webdav plugin provides nice and clean separation of webdav related binding and request processing and backend functionality (serving content from confluence). By exchanging backend and implementing magnolia resource (as opposed to confluence resource) we should be able to reuse this plugin. Randombits webdav plugin have been contributed to confluence. Plugin is using bsd like license which might be in conflict in with our licensing schema.
Clean full implementation of WebDAV protocol and associated specifications
Other option it to implement support from the beginning. To provide full support would be an extensive amount of work (first guess 4-5 man weeks). We can limit time necessary by providing only partial support, yet it might be limiting to certain clients only (each client has little bit specific way of using different features of the server to create and maintain connection and serve the content).
JR WebDAV library
JackRabbit library provide very extensive support - implements all the specs listed above. Limitation here seems to be necessity of using JR authentication. However it is possible to specify default authentication against repository to be used when no other credentials are supplied. Since Magnolia authentication is checked in the logon filter, it is possible to protect access to webdav servlet via existing Magnolia filter chain and only bypasss cms
part of the chain. Since specification mandates the dav resources are not cached, we should at least consider bypassing the cache filter as well.
One existing problem with using Magnolia filter chain for handling authentication to webdav access is the fact that no client (except browsers) is able to cope with the FormLoginCallback. The specification mandates for clients to support Basic authentication only (implemented in BasicLoginCallback
in Magnolia}. Therefore if used we need to extend current callback resolving mechanism to be path aware and allow different callback to be used based on the URI of the request.
The biggest advantage over all other approaches seems to be effort necessary for implementation. JR WebDAV library provides abstract servlet implementation which requires from extending class to provide only public Repository getRepository();
method implementations. So all effort necessary to provide full webdav support is implementation of the method in custom servlet, configuration of filter chain and configuration of security.
12 Comments
Boris Kraft
Note that FTP might be an alternative for the use case of template creation and modification.
Magnolia International
How do we map properties to "files" ? i.e what will I see in my mac's finder when i browse my magnolia instance through webdav ?
Jan Haderka
If you are talking about modifying templates in file system, then yes, FTP is an alternative, otherwise I don't think it would be less work then WebDAV.
When using "SimpleWebDAV" properties are not visible at all. You can use it to move things around and rename nodes but nothing more.
When using "JCRWebDAVServer" each node is a directory and each property is a file. You can then change value of property by editing content of the file.
Magnolia International
alright. Remains to be seen how much usable that is, but that answers my question
How about property types? Can one create properties with this system ?
Philipp Bracher [old account - now Philipp Bärfuss]
All we edit with WebDav are the 'files' (and its content). The properties (meta data, ...) will have to be edited in magnolia itself (dialog, validation, ...).
For MME: templates, css, images? Default JCRWebDAVServer is not usable for that.
All that has been discussed this Tuesday on the phone.
Boris Kraft
The use case for templates is that you can edit the templates using standard client software like GoLive. Hence, there is no need for property manipulation (beyond the file/template name). Everything else can be done inside Magnolia.
Boris Kraft
I would like to see this in the Preview (m-1) so that we can get early feedback from the community regarding how well it actually works for different clients and systems. It will go into the Community Edition as the main use case right now is for easy access to the templates (although DMS will be an obvious candidate once we have rewritten it, sometime in 2009). And making templating easier especially for the casual Magnolia developer is one of the major goals for 3.7.
Philipp Bracher [old account - now Philipp Bärfuss]
About the delete move problem and their solutions:
Solution 1) since most of the users will use other editors than vi we should not punish the majority. This is not an option.
Solution 2) Since the creation as well the recreation depend on the workspace (templates, dms, ..) I think a custom creation handler must be registered in the webdav module config. This is a feature we should probably add anyway.
Solution 3) is not an option as it reverses all the benefits from WebDAV. And in regard of editing CSS and templates it is important to have the very same paths (1:1 feeling)
Solution 4) A forth solution might be to maintain a webdav trash folder in which the deleted (or moved?) nodes are moved into. On recreation of the file we could simply restore it.
Conclusion: Either we invest into the trash based solution (4) or we just live with it. Solution 2 should be added anyway and will reduce the problem to a bearable level.
Jan Haderka
couldn't agree more ... I already started implementing nr. 2 since I need those for new things anyway. Trash would be nice thing to have ... if we do not deliver webdav with 4.0 we might even have time to do it that way.
Boris Kraft
I have had breakfast with John Newton in Boston this week and asked him about their CIFS implementation. Apparently, they provide OEM licenses for their implementation. This could be interesting depending on their terms and conditions. CIFS could then be used as an alternative to WebDAV.
Magnolia International
after observing the current implementation, my feeling is that
Philipp Bärfuss
M5's node type mapping should be introduced in 5.0 and not earlier. It will then become one of the base concepts, similar to the filter chain. If possible I would not go to far here.