Фантазия на тему WebDAV. … сказку сделать былью?
Пост завершает сиквелы:
— Фантазия на тему WebDAV. Штатный Клиент;
— Фантазия на тему WebDAV;
— RESTup — RESTful java сервер консольных приложений или опять о вызове shell из Oracle
Очень краткое содержание:
Выстроганное детище не было расположено к интерактиву с конечным пользователем — имело врожденный порок в виде отсутствия GUI. Шаря по просторам, безутешный родитель наткнулся на лекарство, которое имело побочные эффекты. Поможет ли оно?
+12
1) Параметризация преобразований расширением файла-назначения влечет неоправданные издержки реализации. Первый пример работает, но проще выполнить отдельно распознавание, затем преобразовать результат к требуемому формату.
Управлять пользовательскими свойствами объектов из попавших в обзор клиентов умеет только cadaver (не проверял). Остаются два способа параметризации: именами папок и передачей файла параметров вместе с исходным.
2) Интерфейс предполагает запуск исполнителя по окончании копирования файла (набора файлов) в папку преобразования. Второй пример не сработает, поскольку выяснилось, что большинство штатных клиентов эмулируют метод COPY (Depth: infinity) набором MKCOL, GET/PUT файла. Т.е. действие будет инициироваться для каждого файла в отдельности, но не для пакета файлов в целом. Решение — упаковка набора файлов в zip-архив.
Для этих целей можно завести служебную папку с возможностью создания пользовательской структуры (MKCOL, PUT) и шаблоном (package.zip) архива. Реальная упаковка созданной пользователем структуры происходит только в случае применения метода GET к файлу-шаблону. Методы COPY/MOVE шаблона просто копируют/перемещают структуру (набор файлов) в папку преобразований.
3) Некоторые клиенты передают файл в два приема: сначала нулевой длины, затем — собственно файл. Вероятно придется игнорировать «пустышки».
4) Не все проводники обновляют содержимое папки после передачи файла (исполнения преобразования). Для корректной визуализации результатов придется складывать их во вложенные папки — Result.
5)… not the least: необходимо предоставить пользователю информацию о «правилах игры», сервисах (аннотация, допустимые форматы исходных файлов и формат результата), сведения об ограничениях пользовательской сессии (дисковая квота и таймаут). Эти данные можно разместить в генерируемом txt/html-файле корня сервера.
Здесь БУДЕТ РАЗМЕЩЕНА «действующая модель в натуральную величину». Сроки не называю, но и не прощаюсь. По ходу реализации, если НЛО не против, дополню/уточню и подправлю (формат и стилистику) обзора клиентов.
Эк меня раззадорила полтора года назад статья на Хабре. Спасибо.
