Hi Fazlan, Great. I too don't see this as a hack. After all, using the DAV context for such things is not wrong. Let's test this on Windows and see how it goes.
Thanks, Senaka. On Sun, Apr 17, 2011 at 3:33 PM, Fazlan Sabar <[email protected]> wrote: > 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 > > -- *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
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
