Hi Senaka, I managed to resolve this by maintaining the media-type infomation as session data. This information is stored in the Registry's WebDAV context. We only need to set the following property in davfs.conf. I think this is an obvious choice over putting the burden on configuring different text editors. As underlined in the following description from davfs man page, hence, using session to maintain the media-type info cannot be considered as a hack as well.
*"allow_cookie : Some servers will only work when they are allowed to set a cookie and this cookie is returned in subsequent requests. * * This option adds very simple cookie support. It supports just one cookie which should usually be a session ID. * * 0 = no, 1 = yes. Default: 0"* * * I have only changed the following in the debdav.conf file, and *no editor configuration changes*. use_locks 0 - To get rid of the warning given saying, "/sbin/mount.davfs: warning: the server does not support locks" drop_weak_etags 1 - Because of the above (see the man page) allow_cookie 1 - Enable session tracking However, the first two property settings has no effect on the third property. After this change, gedit, vim and vi worked like a charm. I also, made 'text/plain' as the default mimetype when a file wiith NO extension is created from the Dav client side. We can have a look at what I have done on Monday and arrive at the same page. Furthermore, If this looks good, then we need to test it on other environments such as Windows. However, what we have to make sure is, we clearly document this stuff in the User's Guide so there want be any confusion for the users. On Fri, Apr 15, 2011 at 7:05 PM, Fazlan Sabar <[email protected]> wrote: > Yes, I'll have a look. > > > On Fri, Apr 15, 2011 at 6:26 PM, Senaka Fernando <[email protected]> wrote: > >> Hi Fazlan, >> >> On Fri, Apr 15, 2011 at 4:05 PM, Fazlan Sabar <[email protected]> wrote: >> >>> Hi Senaka, >>> >>> I came across this strange behavior in GReg's webDAV feature, after >>> adding a resource via (Entries -> Add Resource -> Medthod -> Create Text >>> content) from the UI(this enables creation of resources without an >>> extension), irrespective of the specified media-type, it's always shown as >>> plain/text at client(even after setting the getcontenttype property), and >>> editing them with certain editors such as vim and gedit causes the media >>> type information is lost in the process at the server. >>> >>> Why? >>> There behavior of these editors when saving a file not only does a PUT, >>> but also a DELETE request, similar discussion were found at >>> [1]<http://stackoverflow.com/questions/607435/why-does-vim-save-files-with-a-extension>and >>> [2] <http://platform.xwiki.org/xwiki/bin/view/Features/WebDAVDavFs2> . >>> Editors such as vim allows this behavior to be changed, where as gedit does >>> not. In situation such as this, the result at the server end is havoc, >>> because of the DELETE request, which cause the resource to be deleted from >>> the server end. >>> >>> Note: The vi editor does not issue a DELETE operation when saving, hence >>> it's does not involve any tweaks. >>> >>> Possible alternatives: >>> 1) >>> We can set the media-type to 'text/plain' as default for resources >>> created WITHOUT an extension, and use editors like gedit(which does not >>> allow to change the behavior of save) to edit ONLY 'text/plain' type >>> resources. No issue with vim, because the behavior of save can be changed. >>> Impact: This causes some what a coupling between the mime-type and the >>> editor(gedit). However, if the user makes changes to non 'text/plain' type >>> files via gedit, the media-type of the file will get changed to >>> 'text/plain', because it'll treat this file as a new file( since DELETE is >>> performed in the request before). >>> >> >> -1. This is not desirable. We cannot tie ourselves to a specific type of >> editor on a specific OS. And, also, most OSs allow the existence of files >> without a media type, and that's something valid. >> >>> >>> 2) >>> We add the file extension to the requested resource using its media-type >>> at the server end. >>> Impact: The file name will get changed after the first PROPFIND request, >>> but now since the extension of the file is available, the above problem is >>> solved. >>> e.g: >>> we create a resource from UI: name --> xmlfile with Media type --> >>> application/xml >>> and after the webDAV request, its name changes to xmlfile.xml, media-type >>> remains the same. >>> >> >> -1 again. This will break the concepts that we have been having so far in >> G-Reg. We should not transform the file name into something manageable just >> to solve an issue that occurs in the context of a specific type of client. >> >>> >>> 3) >>> We ask the users to use only the editors such as vi and vim that can >>> change the default save behavior when editing files that has no extension, >>> and include these instruction(the ones from the associated links [1] and >>> [2]) in the User Guide of GReg documentation. >>> Impact: Restricts the available editors for modifying resources with no >>> extension. >>> >>> >> >>> WDYT? >>> >> >> This is partially correct. But, this should not be enforced in this >> manner. At the WebDAV servlet, which is our last point-of-contact, we need >> to validate the type of request being made against the current media type of >> the resource and decide whether we allow that kind of operation or not. If >> we cannot handle it, we throw an exception of a known type. When we do >> something like that, it would not be possible to edit some type of file >> using some type of application. This is normal. For example, if you try to >> open a text file using an Archive Manager like file-roller, it will throw an >> exception. >> >> And, for a file of no media type, no editor might might be able to edit >> that. But, normally, when someone creates a file through G-Reg's resource >> UI, he/she would be giving it a media type (when creating text content), or >> we'd be identifying it for him/her. Therefore, I smell some bug in the >> WebDAV implementation that does not carry this information to the >> client-side. Can you have a look into that aspect as well? >> >> Thanks, >> Senaka. >> >>> >>> [1] >>> http://stackoverflow.com/questions/607435/why-does-vim-save-files-with-a-extension >>> [2] http://platform.xwiki.org/xwiki/bin/view/Features/WebDAVDavFs2 >>> -- >>> Thanks, >>> Fazlan >>> >>> >> >> >> -- >> *Senaka Fernando* >> Product Manager - WSO2 Governance Registry; >> Associate Technical Lead; WSO2, Inc.; http://wso2.com* >> Member; Apache Software Foundation; http://apache.org >> >> E-mail: senaka AT wso2.com >> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >> Linked-In: http://www.linkedin.com/in/senakafernando >> >> *Lean . Enterprise . Middleware >> >> > > > -- > Thanks, > Fazlan > > -- Thanks, Fazlan
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
