1. Нет, для «временно залочить» есть LOCK/UNLOCK. HTTP — stateless протокол. А так — да, для получить состав 4-гигового ISO — не обязательно скачивать его весь.
2. Ваш вариант — годный, но выглядит стройной системой костылей и подпорок. Это не ваша беда — это так тут принято. О чем и речь в статье.
3. Я в курсе Домино. Но это — закрытая платформа и «вещь в себе». О сложности и громоздкости я промолчу — дело вкуса.
open — такого нет (HTTP есть stateless протокол)
read — GET
write — PUT
seek — Range header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35)
Можно.
Но подобное я уже пробовал — не прошло проверку на кошках.
Поэтому здесь речь об именно веб-интерфейсе (FrontEnd) и именно WebDAV (BackEnd).
А как MiddleWare — semaweb вполне ничего.
Под Fedora из меню и из ^F2 не запускается. Хотя из CLI — запускается.
И еще смутило:
bash-4.2$ ninja-ide
loaded the Generic plugin
ERROR: Invalid browser function table. Some functionality may be restricted.
java version «1.7.0_06-icedtea»
OpenJDK Runtime Environment (fedora-2.3.1.fc17.2-i386)
OpenJDK Client VM (build 23.2-b09, mixed mode)
Очень хорошо, что Вы всё всегда помните.
Но если проект (не обязательно ПО) разрабатывал один — а сопровождать будет через несколько лет другой — то он хоть как-то должен найти искомое.
Поисковики практически не справляются с этим.
Нет, протокол предоставляет таки прямой доступ (RFC HTTP — partial GET, partial PUT).
А то, что я подкладываю вебдав-провайдеру — это уже второй вопрос.
Схема похожа на FUSE.
Раз уж сегодня — день Микрософт — не могу не вбросить поделиться смищно:
Microsoft не рекомендует использовать встроенныЕ в Microsoft Windows WebDAV-клиенты (да, там их не один) для открывания документов Microsoft Office'ом.
Для этого рекомендуется клиент, встроенный в Microsoft Office.
Так то.
В статье они перечислены, но мне нетрудно выделить:
* возможность ассоциативного поиска (точнее — фильтра)
* кросс-платформенность (клиент и сервер)
* искаропки (клиент)
* Internet
* интегрированность в рабочее окружение
Топик так и написал — «Возможно, это mod_dav несовместим с Windows».
Хотя если бы Вы понаблюдали tcpdump общения Windows по WebDAV — тоже бы очень смеялись.
Поэтому не надо пытаться объять необъятное.
Если дать сотруднику выбор из списка: 1. Контрагента, 2. Типа документа (Договор), 3. Отдела, 4. Исполнителя (это всё — в 4 клика мышом) — то бардак можно сократить на несколько порядков.
А в дальнейшем уже можно уточнить — метаданными, которые вбивают ручками.
Если это маппинг semaweb на ФС — это плохая идея. Честно.
Я не помню уже название того, что я пытался передрать — но я честно передрал (draft) и теги косили под папки.
После демнстрации живым людям оказалось, что это дико неудобно.
После чего на идею подложить semaweb под иерархию я забил.
Это — не выход.
Дабы вернуть обсуждение в русло — попробую краткое резюме статьи (и каментов).
В статье утверждается, что:
1. Оптимальный по куче критериев интерфейс управления файлами клиентом в громадной файлопомойке — веб-интерфейс. Всё остально (симлинки/корпоративные_стандарты_на_папочки/поисковики) — это костыли для изначально нечеловеческой идеи строго иерархической ФС.
2. Оптимальное средство отдачи файлов прямо из этого веб-интерфеса клиенту и назад — WebDAV.
3. Открытых кросс-платформенных средсв для этого — аж одно (alfresco). А для python нет вообще.
4. Python и Django упомянуты для привлечения троллей разработчиков к изготовлению python-based WebDAV provider.
2. Ваш вариант — годный, но выглядит стройной системой костылей и подпорок. Это не ваша беда — это так тут принято. О чем и речь в статье.
3. Я в курсе Домино. Но это — закрытая платформа и «вещь в себе». О сложности и громоздкости я промолчу — дело вкуса.
read — GET
write — PUT
seek — Range header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35)
Но подобное я уже пробовал — не прошло проверку на кошках.
Поэтому здесь речь об именно веб-интерфейсе (FrontEnd) и именно WebDAV (BackEnd).
А как MiddleWare — semaweb вполне ничего.
И еще смутило:
bash-4.2$ ninja-ide
loaded the Generic plugin
ERROR: Invalid browser function table. Some functionality may be restricted.
java version «1.7.0_06-icedtea»
OpenJDK Runtime Environment (fedora-2.3.1.fc17.2-i386)
OpenJDK Client VM (build 23.2-b09, mixed mode)
При чем здесь ява?
Это — backend.
Проблему иерархического доступа к файлам оно не снимает.
Типа:
1. img9.imageshack.us/img9/7513/screenshot257bdecf.png
2. img6.imageshack.us/img6/2764/screenshotd7ffcf8c.png
Но если проект (не обязательно ПО) разрабатывал один — а сопровождать будет через несколько лет другой — то он хоть как-то должен найти искомое.
Поисковики практически не справляются с этим.
Достаточно связать файлы с метаданными — и ищите себе мгновенно по базе данных.
А то, что я подкладываю вебдав-провайдеру — это уже второй вопрос.
Схема похожа на FUSE.
Но это не повод отказываться.
вброситьподелиться смищно:Microsoft не рекомендует использовать встроенныЕ в Microsoft Windows WebDAV-клиенты (да, там их не один) для открывания документов Microsoft Office'ом.
Для этого рекомендуется клиент, встроенный в Microsoft Office.
Так то.
* возможность ассоциативного поиска (точнее — фильтра)
* кросс-платформенность (клиент и сервер)
* искаропки (клиент)
* Internet
* интегрированность в рабочее окружение
Я вел речь не о проектах ПО, а о проектах систем газо/водоснабжения, вентиляции, кондиционирования, строительства и т.д.
Хотя если бы Вы понаблюдали tcpdump общения Windows по WebDAV — тоже бы очень смеялись.
Это хранилище большого количества документов.
Хранилище.
Медленно сортировать — бестро доставать.
Если дать сотруднику выбор из списка: 1. Контрагента, 2. Типа документа (Договор), 3. Отдела, 4. Исполнителя (это всё — в 4 клика мышом) — то бардак можно сократить на несколько порядков.
А в дальнейшем уже можно уточнить — метаданными, которые вбивают ручками.
Я не помню уже название того, что я пытался передрать — но я честно передрал (draft) и теги косили под папки.
После демнстрации живым людям оказалось, что это дико неудобно.
После чего на идею подложить semaweb под иерархию я забил.
Это — не выход.
В статье утверждается, что:
1. Оптимальный по куче критериев интерфейс управления файлами клиентом в громадной файлопомойке — веб-интерфейс. Всё остально (симлинки/корпоративные_стандарты_на_папочки/поисковики) — это костыли для изначально нечеловеческой идеи строго иерархической ФС.
2. Оптимальное средство отдачи файлов прямо из этого веб-интерфеса клиенту и назад — WebDAV.
3. Открытых кросс-платформенных средсв для этого — аж одно (alfresco). А для python нет вообще.
4. Python и Django упомянуты для привлечения
троллейразработчиков к изготовлению python-based WebDAV provider.В моем велосипеде файлы как раз организованы в виде записей в БД.