|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Evgeny Kazanov 2:5020/400 24 Apr 2001 23:14:36
To : All
Subject : Re: Novell vs Linux
--------------------------------------------------------------------------------
Vladimir Bormotov <bor@vb.dn.ua> wrote:
>
> 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> - изучать неохота, так как кажется отдача непропорциональна усилиям
Да, про PHP у тебя есть мнение - не нравится.
А у меня про Zope - нет.
Как эта система по отношению усилия/отдача?
PHP/MySQL или PHP/Postgres я не сходя с места компах на трех могу
использовать.
А Zope интуитивно чувствую на одном - у себя дома.
А преимущества?
>
> 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> А может кто-нибудь уже видел что-нибудь подобное? Hапример написанное
> EK >нi PH people know: NEVER eat yellow snow!
>
> Вот какой-то GroupWare есть написаный на Zope. URL думаю можно найти или в
> подшивках Dr.Dobbs Python URL, или PythonWare Daily URL... В любом случае,
> google должна помочь, в обмен на дополнительно потраченое время ;)))
>
Hадо попробовать
-------------------
Да, вот ... вспомнил как раз ... насчет решений Майкрософт ... поговорку:
Experience people know: NEVER eat yellow snow!
--
- ---
Evgeny Kazanov
http://visaginas.is.lt/~evgeny
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
