- PVSM.RU - https://www.pvsm.ru -

Идеальное хранилище документов

Иногда очень хочется быстро найти нужный файл. С учетом того, что файлов — сотни тысяч, а ты не знаешь ни его названия, ни содержания, ни типа — ничего. Зато приблизительно знаешь категории. И хочется его быстро вычислить и сразу же отредактировать и записать.
На сегодня удобных кросс-платформенных open-source файлопомоек с прямым доступом к файлам — НЕТ.
Далее речь пойдет не о медиабиблиотеке и не о semaweb — а о простой и удобной системе управления громадной файлопомойкой с прямым доступом к файлам.

1. ТЗ

Британские ученные Практика показала, что даже в небольшой фирме на пару десятков пользователей может скопиться не один десяток (а то и сотни) тысяч файлов — самого разного содержания и формата. И найти в этом бардаке хозяйстве файл бывает настолько трудно, что проще сделать всё заново.
Проблема поиска возникла сильно не сегодня (Чехов [1] свидетель) — но пока не решена.
Нюанс в том, что в данном случае «найти» — это не в терминах поисковиков или Проводника — а в терминах человеческих. Человек на знает слова, которые он ищет — он знает понятия. А с понятиями (семантикой) у поисковых машин и файломанагеров туго. Ибо нормальный пользователь не ищет “\serverpublicВходящиеДоговорыКлиентыРога и КопытаДоговор Рога и копыта с Ромашка на поставку.doc” — он ищет “Какой-то договор примерно в прошлом месяце с нашим любимым клиентом примерно на два лимона”. И найдет он его (если повезет) в “\serverprivateсекретаршаИсходящиеООО “Ромашка”Коммерческие предложенияКопытоКак они меня уже достали.xls”.
В ситуации “они сами не знают, чего хочут” (© Зощенко) надо дать человеку выбор (что и пытаются делать поисковики, но пока что безуспешно). Т.е. я не знаю тип документа — у меня перед глазами возможные типы. Я не помню точное название фирмы — у меня список фирм. И т.д. Поэтому это уже не поиск — а фильтр.
Итак — допустим у меня есть 100500000 файлов (от прона до чертежей AutoCAD) — и я хочу быстро и удобно:

  1. «вычислить» (отфильтровать) файл по неким признакам, которых физически в самом файле нет,
  2. открыть (не скачать и открыть его копию — а открыть именно его),
  3. изменить — и записать (не закачать назад — а именно записать — ^S).

Итого — нам нужна система, которая:

  • Работает
  • Кросс-платформенное (Windows, Linux, Mac OS)
  • Фильтры
  • Прямой доступ (открыть и записать)
  • Интеграция (интегрированность в окружение рабочего стола — как следствией п.4)
  • Многопользовательское
  • Internet (доступ из любой точки мира)
  • Open source

2. Кто виноват

Что мы имеем на сегодня:

2.1. FS

Речь идет о файлопомойке в виде развесистого дерева папок и файлов на локальной/удаленной файловой системе. Этот вариант имеет одно крупное достоинство и один крупный недостаток:

  • — Полное отсутствие фильтров.
  • + Встроенный кросс-платформенный прямой доступ к файлам.

Конечно — иерархическое построение можно с натяжкой назвать “фильтром”. Но именно с натяжкой. Ибо если один человек положил файл в “\serverpublicООО РомашкаДоговораНа поставку” — а другой ищет его в “\serverpublicЮротделИсходящиеРомашка” — то это ни разу не соответствует ассоциативному мышлению [2] человека. На само деле этот файл должен быть “Юротдел” И “Исходящие” И “Ромашка” И “Договор” — причем не в таком порядке, а одновременно. А вот одновременно текущие файломанагеры не обеспечат.

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-провайдеры, а именно серверы). Пришлось читать буквы [3] и начинать лепить свой велосипед. Букв довольно много, в одиночку дело идет медленно, поэтому приглашаю желающих к совместной разработке.
Слайды [4].

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


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/python/14748

Ссылки в тексте:

[1] Чехов: http://public-library.narod.ru/Chekhov.Anton/loshadin.html

[2] мышлению: http://www.braintools.ru

[3] буквы: http://tools.ietf.org/html/rfc4918

[4] Слайды: http://dox.eap.su/testdav/