Пост завершает сиквелы:
— Фантазия на тему WebDAV. Штатный Клиент;
— Фантазия на тему WebDAV;
— RESTup — RESTful java сервер консольных приложений или опять о вызове shell из Oracle

Очень краткое содержание:
Выстроуганное* детище не было расположено к интерактиву с конечным пользователем — имело врожденный порок в виде отсутствия UI. Шаря по просторам, безутешный родитель наткнулся на сильнодействующее лекарство. Поможет ли оно?
+21

1) Параметризация преобразований расширением файла-назначения влечет неоправданные издержки реализации. Первый пример работает, но проще выполнить отдельно распознавание, затем преобразовать результат к требуемому формату.
Вдогонку. Переименование файлов у всех клиентов реализовано методом MOVE (в Request-Line исходный файл, в Destination новый). Как вариант, параметризовать операцию можно изменяя расширение и|или имя файла. Первый пример может выглядеть так:

cp ~/images/document.jpg   /dav/transform/ 
mv /dav/transform/document.jpg   /dav/transform/document[+90].jpg
mv /dav/transform/document*.jpg   /dav/transform/document[rus].txt
mv /dav/transform/document*.txt   /dav/transform/document.doc
mv /dav/transform/document.doc   ~/texts/

Сопоставить расширения файлов и параметр(ы) с требуемым действием сложно, но можно. Сработает и для проводников. Заодно решаются несколько вопросов, включая п.4, п.3?

Управлять пользовательскими свойствами объектов из попавших в обзор клиентов умеет только cadaver (не проверял). Остаются два способа параметризации: именами папок и передачей файла параметров вместе с исходным.
Вдогонку. Погорячился. Жизнь не стоит на месте. RFC в пользовательских свойствах объектов допускает XML-типы. Как там с перечислениями фиксированных значений? Стоит разобраться.

2) Интерфейс предполагает запуск исполнителя по окончании копирования файла (набора файлов) в папку преобразования. Второй пример не сработает, поскольку выяснилось, что большинство штатных клиентов эмулируют метод COPY (Depth: infinity) набором MKCOL, GET/PUT файла. Т.е. действие будет инициироваться для каждого файла в отдельности, но не для пакета файлов в целом. Решение — упаковка набора файлов в zip-архив.

Для этих целей можно завести служебную папку с возможностью создания пользовательской структуры (MKCOL, PUT) и шаблоном (package.zip) архива. Реальная упаковка созданной пользователем структуры происходит только в случае применения метода GET к файлу-шаблону. Методы COPY/MOVE шаблона просто копируют/перемещают структуру (набор файлов) в папку преобразований.

3) Некоторые клиенты передают файл в два приема: сначала нулевой длины, затем — собственно файл. Вероятно придется игнорировать «пустышки».

4) Не все проводники обновляют содержимое папки после передачи файла (исполнения преобразования). Для корректной визуализации результатов придется складывать их во вложенные папки — Result.

5)… not the least: необходимо предоставить пользователю информацию о «правилах игры», сервисах (аннотация, допустимые форматы исходных файлов и формат результата), сведения об ограничениях пользовательской сессии (дисковая квота и таймаут). Эти данные можно разместить в генерируемом txt/html-файле корня сервера.

Здесь БУДЕТ РАЗМЕЩЕНА «действующая модель в натуральную величину». Сроки не называю, но и не прощаюсь. По ходу реализации, если НЛО не против, дополню/уточню и подправлю (формат и стилистику) обзора клиентов.
Вдогонку. Похоже, идея еще не дозрела.

Эк меня раззадорила полтора года назад статья на Хабре. Спасибо.

7-10 октября 2015
* строгать|стругать Второе каноничней: стружка.