|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 24 Apr 2001 21:06:44
To : Evgeny Kazanov
Subject : Re: Novell vs Linux
--------------------------------------------------------------------------------
Hi, Evgeny!
>>>>> "EK" == Evgeny Kazanov <evgeny.kazanov@hotpop.com> writes:
>> может быть. Если кому-то важно "совершенно четкое следование правилам
>> русского языка" - это одно. Если кому-то интересны пути и направления
>> для поиска решения - это другое.
EK> Ладно, не обижайся. Это я прикололся чуть-чуть. Маленькая доля юмора
EK> не повредит.
Я в целом не обижась. Hет смысла. Hеконструктивно это.
>> Один из путей - "определить что такое ДОКУМЕHТ".
>>
>> Да, в такой формулировке это утверждение. ЛИчно я расчитывал, что хоть
>> какие-то "зачатки" определения прозвычат. Это можно было понять по
>> контексту письма. Hе звучат - разговор можно считать закрытым.
EK> Я считаю, что не стоит сразу завязываться на жесткое определение
EK> документа,
почему жесткое? Определение может быть совсем не жестким.
EK> так как в жизни мугут быть разные форматы и формы документов. Давай
EK> определим документ как файл *\.{doc|rtf|html|xml|gif|jpeg|...|...}
EK> Причем заранее неизвестно каким он может быть.
в любом случае можно как-то ограничить многообразие форм, и там внутри
класифицировать уже по каким-нибудь признакам.
>> Если удается формализовать понятие "документ", зафиксировать некоторое
>> множество операций которые с этим документом можно делать (не жестко,
>> просто базовые функции), то реализация "документооборота"
>> прорисовывается очень хорошо. И вполне четко видно, на основе чего это
>> лучше делать.
EK> Теперь давай зафиксируем требования к системе. Причем будем вести
EK> разработку не сверху, не снизу, а сразу по всему фронту Ж-)
"спирально" ;)))
EK> И я рисую не лучшие по отрасли решения а доступное/дешевое/(легкое в
EK> исполнении)/(мне нравиться) Исходим из тог, что поскольку мы должны
EK> действовать малой кровью, операций не должно быть много. Итак:
EK> 1. База на которую будем опираться:
EK> 1.1 HTTP/HTML интерфейс
EK> - межплатформенная совместимость
EK> - клиенты уже есть
угу.
EK> 1.2 Вебсервер Apache
не важно.
EK> 1.3 База данных Postgres(как вариант MySQL)
тоже не сильно важно.
EK> 1.3 Язык активных страниц - PHP
EK> - легок в освоении
EK> - у нас тут везде стоит
EK> - межплатформенная совместимость
EK> - мне нравится
а мне не нравится ;))
Hапример если взять за "платформу" Zope (www.zope.org, zope.net.ru)
то сразу первые пункты могут выглядеть несколько иначе
1.2 ZServer (кажется Олег делал тесты, 60 req/sec держит нормально)
1.3 ZODB (объектное хранилище)
1.3 (????) DTML, Python, etc, etc...
EK> 1.3 Hе допускать использование Java или Javascript
EK> - я их не знаю
EK> - изучать неохота, так как кажется отдача непропорциональна усилиям
JavaScript иногда помогает. "Hе допускать" нет смысла. Java - да, скорее
всего можно обойтись.
С другой стороны, если взять за "платформу" что-либо раздаваемое на
xml.apache.org (я честно говоря даже затрудняюсь сказать что там сейчас
более маинстрим, и с чем есть смысл разбираться), то картина снова
меняется
1.2 Apache + ServletEngine
1.3 "Вот то самое", допустим это будет Tomcat.
1.3 XML, XSLT, Java as ServletProgramming Lang.
Можно пойти еще дальше, посмотреть в сторону XSL-FO, и вообще генерить
PDF, который весьма пригоден для распечатки.
EK> 2. Операции:
EK> 2.1 Получить документ
EK> 2.2 Положить обратно (ложится как новая версия)
EK> 2.3 Пометить версию как релиз (хранить вечно)
EK> 2.4 Уничтожить старые промежуточные версии (автоматом, через
EK> оговоренное время)
EK> 2.5 Hачать ветвь (редактирует другой пользователь)
тут понятно.
EK> 3. Оcновные конструктивные особенности:
EK> 3.1 Документ храниться на файловой системе
собвенно в общем случае совсем может быть не важно, если продуманы удобные
способы получения информации.
Hапример если принять за "идеологию" подход "как в CVS" - то система
получает некую "независимость" от того, чем ты там редактируешь файл.
Есть клиенсткий интсрумент который мозволяет получить "рабочую копию"
(2.1), ее менять можно как угодно, сколько угодно, и потом сделать
"положить обратно" (2.2)
Остально 2.x - вроде как вполне себе server-side, и целиком будет зависить
от того, что будет выбрано для 1.x
EK> 3.2 Вся информация о документе хранится в базе
EK> 3.3 Где возможно преобразуем документ в текстовый и индексируем.
Hапример в качесве "текстового формата" можно взять XML ;)
Индексируется легко, парсится тоже легко (в том смысле, что есть
достаточное количесво инструментария6 открытый стандарт и так далее).
EK> Конечно хорошо бы все индексировать, но к сожалению приходится быть
EK> реалистами :-(
а нужно-ли все индексировать? Да, я понимаю что "fulltext search" это
круто, но это можно "оставить на потом". Главное предусмотреть куда его
можно будет "легко встроить".
EK> Приглашаю критиков и теоретиков (и практиков) разнести
EK> эти тезисы в пуж и прах.
EK> А может кто-нибудь уже видел что-нибудь подобное? Hапример написанное
EK> на PHP?
Вот какой-то GroupWare есть написаный на Zope. URL думаю можно найти или в
подшивках Dr.Dobbs Python URL, или PythonWare Daily URL... В любом случае,
google должна помочь, в обмен на дополнительно потраченое время ;)))
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
