Не стреляйте в пианиста. Он играет, как умеет.
Протокол WebDAV, как я его понимаю, является расширением HTTP методами совместной работы с коллекциями объектов их свойствами и версиями.Типичным примером коллекций являются файловые системы, а применительно к WEB — облачные хранилища файлов. Взаимодействие с некоторыми из них возможно с помощью клиентских WebDAV приложений любой современной OC.
Предлагаю взглянуть на коллекции с несколько иной стороны: рассматривать их не только как контейнер, но и как фильтр, т.е. некоторое фиксированное действие по преобразованию объектов к определенному типу. Применительно к файлам, это могут быть папки оптического распознавания символов, папки взаимного преобразования документов из одного вида в другой (doc, xlsx, pdf, odt, html,...), папки архивирования (zip, tar, rar) и т.д. Помещаемый в эти папки-фильтры файл 'на лету' преобразуется в соответствующий вид.
Цепочки преобразований реализуются копированием из одной удаленной папки в другую. Последовательность 'повернуть изображение — распознать' (опуская монтирование davfs) на стороне клиента может выглядеть следующим образом:
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/
В предложенном примере вид и параметры преобразования определяется именем папки, а формат результата — расширением файла-назначения. «Тонкую» параметризацию преобразования логично выполнить изменяя свойства коллекции (виртуальной пользовательской папки) или более традиционным путем — передачей файла параметров в одном пакете с исходным.
Пакетирование может потребоваться и в случаях, когда необходим набор файлов без которого действие, инициируемое по завершению копирования, приведет к ошибочному результату. Целям пакетирования файлов может служить виртуальная папка временного хранения. Последовательность действий по проверке пакета xml-файлов, результатом которой является файл протокола, может выглядеть так:
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/
Поскольку для папок преобразований излишни совместный доступ, поддержка версионности и долговременное хранение (наоборот, доступ должен быть ограничен монопольной сессией пользователя, а невостребованные файлы — удалены по истечении таймаута сессии), для реализации интерфейса будет достаточно ограниченного набора методов WebDAV класса 1.
Эта странная идея посетила меня в период размышлений над пользовательским интерфейсом к RESTful серверу консольных приложений. Изложенный подход представляется более гибким, а реализация — не сложнее традиционного WEB-решения для браузеров.
Goodkat
Думал о таком в детстве, только вместо копирования в нужную папку предполагал чтение из нужной папки:
Допустим, у вас на сервере лежит файл /dav/images/example.jpg
Для него показывается структура типа
./original/example.jpg
./300x300/example.jpg
./800x600/example.jpg
и т.п.
Файлы эти не существуют, но создаются на лету при обращении к ним.
Проблема, как и в вашем случае — для каждого файла будет существовать большое количество папок для поддерживаемых вариантов действий.
miktim
В детстве деревья были большими и технологии несколько иными. Допускаю, что идея не нова и может быть реализована в файловой системе перехватом.
О параметризации — в 4-м абзаце, но кто сказал, что количество папок преобразований (при правильной структуризации) — зло? Есть поиск. Есть иные организационные приемы, о чем позже. А пока — продолжение темы.
Ваши слова «для каждого файла» я понял как «для каждого типа (расширения) файла». Да, действительно, количество папок может соответствовать количеству преобразований, но для любого файла изображения.
toxicdream
В протоколе DLNA и серверах его реализующих есть подобные извороты.
Кому-то нравится, кому-то — нет.
miktim
Ну, велосипед — так велосипед. Увы, за всем не уследишь.