Иногда очень хочется быстро найти нужный файл. С учетом того, что файлов — сотни тысяч, а ты не знаешь ни его названия, ни содержания, ни типа — ничего. Зато приблизительно знаешь категории. И хочется его быстро вычислить и сразу же отредактировать и записать.
На сегодня удобных кросс-платформенных open-source файлопомоек с прямым доступом к файлам — НЕТ.
Далее речь пойдет не о медиабиблиотеке и не о semaweb — а о простой и удобной системе управления громадной файлопомойкой с прямым доступом к файлам.
1. ТЗ
Британские ученные Практика показала, что даже в небольшой фирме на пару десятков пользователей может скопиться не один десяток (а то и сотни) тысяч файлов — самого разного содержания и формата. И найти в этом бардаке хозяйстве файл бывает настолько трудно, что проще сделать всё заново.
Проблема поиска возникла сильно не сегодня (Чехов свидетель) — но пока не решена.
Нюанс в том, что в данном случае «найти» — это не в терминах поисковиков или Проводника — а в терминах человеческих. Человек на знает слова, которые он ищет — он знает понятия. А с понятиями (семантикой) у поисковых машин и файломанагеров туго. Ибо нормальный пользователь не ищет “\serverpublicВходящиеДоговорыКлиентыРога и КопытаДоговор Рога и копыта с Ромашка на поставку.doc” — он ищет “Какой-то договор примерно в прошлом месяце с нашим любимым клиентом примерно на два лимона”. И найдет он его (если повезет) в “\serverprivateсекретаршаИсходящиеООО “Ромашка”Коммерческие предложенияКопытоКак они меня уже достали.xls”.
В ситуации “они сами не знают, чего хочут” (© Зощенко) надо дать человеку выбор (что и пытаются делать поисковики, но пока что безуспешно). Т.е. я не знаю тип документа — у меня перед глазами возможные типы. Я не помню точное название фирмы — у меня список фирм. И т.д. Поэтому это уже не поиск — а фильтр.
Итак — допустим у меня есть 100500000 файлов (от прона до чертежей AutoCAD) — и я хочу быстро и удобно:
- «вычислить» (отфильтровать) файл по неким признакам, которых физически в самом файле нет,
- открыть (не скачать и открыть его копию — а открыть именно его),
- изменить — и записать (не закачать назад — а именно записать — ^S).
Итого — нам нужна система, которая:
- Работает
- Кросс-платформенное (Windows, Linux, Mac OS)
- Фильтры
- Прямой доступ (открыть и записать)
- Интеграция (интегрированность в окружение рабочего стола — как следствией п.4)
- Многопользовательское
- Internet (доступ из любой точки мира)
- Open source
2. Кто виноват
Что мы имеем на сегодня:
2.1. FS
Речь идет о файлопомойке в виде развесистого дерева папок и файлов на локальной/удаленной файловой системе. Этот вариант имеет одно крупное достоинство и один крупный недостаток:
- — Полное отсутствие фильтров.
- + Встроенный кросс-платформенный прямой доступ к файлам.
Конечно — иерархическое построение можно с натяжкой назвать “фильтром”. Но именно с натяжкой. Ибо если один человек положил файл в “\serverpublicООО РомашкаДоговораНа поставку” — а другой ищет его в “\serverpublicЮротделИсходящиеРомашка” — то это ни разу не соответствует ассоциативному человека. На само деле этот файл должен быть “Юротдел” И “Исходящие” И “Ромашка” И “Договор” — причем не в таком порядке, а одновременно. А вот одновременно текущие файломанагеры не обеспечат.
2.2. Web
Тысячи их. Отвечает всем требованиям, кроме двух:
- — Прямой доступ к любым файлам (Гугледокс и MS Live — это хорошо — но что делать людям с AutoCAD и SmetaWizard?)
- — Интеграция (как следствие)
Т.е. частичный доступ
2.3. All-in-one
IBM Domino, MS SharePoint, MS Exchange. Это такое “вещь в себе”, которое пытается своими средствами порешать недостатки существующих технологий.
- + Работает
- + Фильтры
- + Прямой доступ
- + Многопользовательское
- + Internet
- — Не кросс-платформенное
- — Не интегрировано
- — Не open source
2.4. Semantic FS
Nepomuk, WinFS, ReFS etc. При всем уважении я их вживую работающими не видел, поэтому — не рассматривается наряду с другой экзотикой.
3. Что делать
Если кратко — вешаться использовать web-интерфейс для управления файлами и давать ссылку прямого доступа к файлам.
С ссылками всё очень просто — особо не развернешься. Если исходить из кросс-платформенности — то вариантов (из тех, что не требуют специальных приседаний) аж 3: http://, ftp:// и file:// (больше венда нормально не понимает). При этом метаданные файлов можно организовать как угодно — от простых тегов до semaweb-наворотов. А вот с ссылками надо подумать.
3.1. HTTP
Только чтение. В смысле — дать ссылку http:// можно — и даже можно скачать, открыть и изменить. Но залить точно туда же — не получится. Комбинацией ^S по крайней мере. Из любого приложения под любой платформой.
3.2. FTP
Наверное можно каким-то образом скрестить веб-интерфейс со ссылками на файлы в ftp. Но гарантированно обеспечить целостность информации в базе метаданных и в ftp-хранилище довольно сложно — это два совершенно отдельных сервиса. Вмешаться в работу ftp-сервера — очень тяжело, а писать свой ftp-сервер…
Отставить.
3.3. file://
Откровенный костыль. Т.е. можно как-то замапить удаленный ресурс на локальный по какому-то из интернет-протоколов — и даже будет работать. Но выглядит эта конструкция слишком феерично.
3.4. WebDAV
А вот тут всё очень интересно. Как такового — “стандартного” сервера WebDAV нет. Зато все распространенные ОС/DE поддерживают WebDAV (как клиенты) из коробки и множеством способов. При этом можно написать свою собственную WebDAV на стороне сервера (не веб-сервер — а только обработку http request) и вытворять буквально чудеса.
Теоретически, конечно…
4. А при чем здесь Django?
При том, что демонстрация этой идеи (Web UI + WebDAV) использует как раз Django (более точно — это небольшой комплект из Apache, mod_dav, Django и программки, сделанной на скорую руку специально для этой статьи). А дабы внимательный читатель внимательно дочитал — ссылка на демо — где-то в тексте :-)
Демонстрируется, в частности, управление файлами через web (поле «comment» для файлов) — и прямой доступ к файлу прямо из веб-страницы.
Хотелось, конечно, получить полное турбо от WebDAV — но внезапно оказалось, что из тысяч реализаций WebDAV-провайдера на python — оба (wsgidav и pywebdav) довольно сложно встроить в своё веб-приложение (если вообще возможно, т.к. это не WebDAV-провайдеры, а именно серверы). Пришлось читать буквы и начинать лепить свой велосипед. Букв довольно много, в одиночку дело идет медленно, поэтому приглашаю желающих к совместной разработке.
Слайды.
5. Комментарии
Linux
Konqueror с webdav:// работает отлично. Правда — только приложения KDE или же адаптированные к нему (libreoffice-kde) — по крайней мере при работе не в KDE. Т.е. интеграция тут только частичная (Пользователи LibreCAD, JuffEd и других не KDE приложений вынуждены сосать лапу.).
Epiphany с dav:// — аналогично (s/KDE/GNOME/). Хотя гном с WebDAV работает похуже, чем кеды.
Mac OS
Не тестировалось
Windows
Т.к. на хабре применение обсценной лексики не приветствуется, то резюме будет краткое — всё очень плохо. Об “особенностях” взгляда Microsoft на WebDAV, HTTP и XML можно написать книгу.
Но при определенном положении звезд кое-что кое-как кое-когда таки работает.
Хотя, возможно, апачевый mod_dav не слишком совместим с Windows ;-)
6. Резюме
Вся эта стройная система костылей и подпорок работает, но не фонтан. В любой ОС (клиента). Т.е. на текущий момент ОС/DE не вполне готовы к полной интеграции веб-приложений с десктопом (так, чтобы прозрачно и всегда).
Но жизнь на Марсе всё-таки есть!
Автор: TIEugene
