It is definitely better to start something new for implementation in Restlet, but the good news is it should be easy. The GoGoEgo WebDAV implementation is very closely tied to the GoGoEgo VFS layer and doesn't really use the Directory abstraction of Restlet as a Restlet user would expect. However, it does give an example of a working WebDAV on Restlet, and illustrates that very little is required to achieve basic DAV interoperability. The direction I had been hoping for was to build sufficient DAV 1 features and hacks straight into the Directory plumbing (COPY, MOVE, PROPFIND, PROPPATCH) that any Restlet Directory could be trivially used with Web Folders, WebDrive, OS X, wdfs and the like. I think this integration would be very useful to many people.
I feel that an extension would be the right place to land a more completely feature-filled WebDAV implementation that actually supports custom properties in PROPFIND/PROPPATCH, LOCK/UNLOCK, and so forth. This requires concepts that are not in HTTP (see some of the critical analysis linked to the RFE) and can be argued are not even RESTful. This almost certainly needs to live in an extension. A small digression (which I should put in the RFE) ... Operating systems' native WebDAV client implementations are typically afterthoughts and not really meant to be platform-interoperable. Windows Web Folders is meant to work well connecting to IIS and not particularly anything else. OS X and even Linux also tend to have their own expectations of compliant server behavior; for example, Nautilus "likes" Apache mod_webdav but sometimes cannot navigate on other WebDAV servers (this is on my list of things to investigate some day). Anyway, the hacks which enable each client to work well are frequently ugly, and sometimes mutually exclusive. Restlet, as a body of work, has been remarkably free of hacks. So if these clients are to all be supported, care should be taken so that the hacks can be enabled or disabled, and potentially limited to the afflicted user agents. - R On Wed, Jun 25, 2008 at 4:56 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > Hi Jean-Yves, > > There is indeed an existing plan to improve support for WebDAV in Restlet > 1.2. It would be great if you could participate and contribute some > features. See this RFE: > > "Support WebDAV COPY and MOVE methods" > http://restlet.tigris.org/issues/show_bug.cgi?id=346 > > Rob Heittman, who is also behind GoGoEgo, created this RFE and proposed > some > enhancements. He might be interested in helping you out. > > There are two path regarding Restlet and WebDAV that we could explore IMO: > > 1) Enhance the current Directory class to support COPY and MOVE and maybe > other 'simple' features by default. > > 2) Add a new "com.restlet.ext.webdav" extension that would provide more > complete and compliant Client and Server WebDAV connectors. > > What do you think? > > Best regards, > Jerome > > > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Jean-Yves Cronier > Envoyé : mercredi 25 juin 2008 00:12 > À : [email protected] > Objet : Re: Standard status-line in Status > > I am playing to development of an lightweight (and very partial) > implementation of WebDAV protocol. > > (By the way, about this, I wonder how would it make more sense to > develop it, so that I can give it to the RESTlet community) > > In short, in the specifications WebDAV, to describe the content of > "collections", I need for each resource, to indicate its status: > http://www.webdav.org/specs/rfc2518.html#ELEMENT_status > > Is there an issue (in your bugtracker) (targetting for RESTlet 1.2 ?) > covering the implementation of WebDAV and with advices on how to > implement it? If yes, I will be happy to work on it! > > Can we try to be inspired with GoGoEGO's code ? Or is it better to start > a totaly new one ? > > > > > > > Jerome Louvel wrote: > > Hi Jean-Yves, > > > > Internally the NRE (Restlet engine) does convert the Status instance to > the > > standard format (see > > com.noelios.restlet.http.HttpServerCall#writeResponseHead () method). > > > > The Status#toString() method just provides a convenient/simple string > value. > > Do you have a specific use case that requires this value to conform to > the > > HTTP spec? > > > > Best regards, > > Jerome > > > > -----Message d'origine----- > > De : news [mailto:[EMAIL PROTECTED] De la part de Jean-Yves Cronier > > Envoyé : lundi 23 juin 2008 01:09 > > À : [email protected] > > Objet : Standard status-line in Status > > > > As defined in RFC2616 (6.1) > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1 > > > > Is it better to change org.restlet.data.Status#toString() to comform to > > [HTTP-Version SP Status-Code SP Reason-Phrase CRLF] ? > > > > If no: What is the best way to build "Status-Line" of a > > org.restlet.data.Status ? > > > > > >
