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