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
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
