Do not shoot the pianist. He plays as he can.The WebDAV protocol, as I understand it, is an extension of HTTP by methods of working with collections of objects, their properties and versions. A typical example of collections is file systems, and in relation to WEB - cloud file storages. Interaction with some of them is possible using WebDAV client applications of any modern OC.
I suggest looking at the collections from a slightly different side: to consider them not only as a container, but also as a filter, i.e. some fixed action for converting objects to a specific type. In relation to files, these can be folders of optical character recognition, folders of mutual conversion of documents from one type to another (doc, xlsx, pdf, odt, html, ...), archiving folders (zip, tar, rar), etc. . The file placed on the fly (the PUT method) is converted to the appropriate form in these filter folders.
Transformation chains are implemented by copying (MOVE, COPY methods) from one remote folder to another. The sequence 'rotate image - recognize' (omitting mount davfs) on the client side may look like this:
cp ~/images/document.jpg /dav/convert/images/rotate90/ mv /dav/convert/images/rotate90/document.jpg /dav/convert/images/ocr(rus)/document.docх mv /dav/convert/images/ocr(rus)/document.* ~/texts/
In the proposed example, the type and parameters of conversion are determined by the name of the folder, and the format of the result is determined by the extension of the destination file. It is logical to carry out the “thin” parameterization of the transformation by changing the properties of the collection (virtual user folder) or in a more traditional way - by transferring the parameter file in one package with the original one.
Packing may also be required in cases where a set of files is needed without which the action initiated when the copy is completed will lead to an erroneous result. The purpose of file packaging can serve as a virtual temporary storage folder. The sequence of actions for checking a package of xml files, the result of which is a protocol file, may look like this:
cp ~/document1.xml /dav/storage/ cp ~/document2.xml /dav/storage/ ... cp ~/documentN.xml /dav/storage/ cp /dav/storage/ /dav/check/checkxml/ mv /dav/check/checkxml/storage/protocol.html ~/result/
Since conversion folders are unnecessary for sharing, versioning support, and long-term storage (on the contrary, access should be limited to exclusive user sessions, and unclaimed files should be deleted after the session timeout), a limited set of WebDAV class 1 methods will be enough to implement the interface.
This is a strange idea visited me while thinking about the user interface to a RESTful console application server . The presented approach seems more flexible, and the implementation is no more complicated than the traditional WEB-solution for browsers.
Sandbox, June 2015.