|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Evgeny Kazanov 2:5020/400 24 Apr 2001 19:36:23
To : All
Subject : Re: Novell vs Linux
--------------------------------------------------------------------------------
Vladimir Bormotov <bor@vb.dn.ua> wrote:
>
> Hi, Evgeny!
>
>>>>>> "EK" == Evgeny Kazanov <evgeny.kazanov@hotpop.com> writes:
>
>>>>> Для начала, нужно определить что такое "документ" ;))))
>>>
>>> Hа этот вопрос ответа не будет?
> EK> Это не вопрос, а утверждение. В конце вопросительных предложений стоит
> EK> знак вопроса.
>
> может быть. Если кому-то важно "совершенно четкое следование правилам
> русского языка" - это одно. Если кому-то интересны пути и направления для
> поиска решения - это другое.
Ладно, не обижайся. Это я прикололся чуть-чуть.
Маленькая доля юмора не повредит.
>
> Один из путей - "определить что такое ДОКУМЕHТ".
>
> Да, в такой формулировке это утверждение. ЛИчно я расчитывал, что хоть
> какие-то "зачатки" определения прозвычат. Это можно было понять по
> контексту письма. Hе звучат - разговор можно считать закрытым.
>
Я считаю, что не стоит сразу завязываться на жесткое определение документа,
так как в жизни мугут быть разные форматы и формы документов.
Давай определим документ как файл *\.{doc|rtf|html|xml|gif|jpeg|...|...}
Причем заранее неизвестно каким он может быть.
>>> EK> А NT - по идеологическим причинам не катит. И не говорите, что эти
>>> EK> причины не важные. Важные и еще как.
>
>>> Мне - не важны.
> EK> А если тебе не важно, то какой твой интерес в этом разговоре?
>
> Как обычно - деньги. ;)
>
>
> EK> Да я спорить и не собираюсь. Мне это как бы неинтересно. Мне
> EK> интересно наименьшей кровью привести вещи в более менее порядок, не
> EK> используя дополнительных денежных вливаний.
>
> вооот. Собвенно это интересно всем. Даже мне ;)
> Потому что "не использование больших вливаний в софт", может перетечь в
> "небольшие вливания в мой карман" ;)
>
> EK> Желательно используя линукс. По многим причинам. Одна из них то, что
> EK> мои друзья сделали небольшую провайдерскую фирму, используя только
> EK> Линукс. Для документов они используют СтарОфис.
>
> как уже говорилось - на данном этапе обсуждения это практически не
> сущесвено.
>
> EK> Что касается отношения цена/отдача, то:
> EK> 1. В наших краях воровать софт опасно,
> EK> особенно в коммерческих структурах - конкуренты могут запросто
> EK> сдать. Моя фирма собирается потратить $250k на легализацию софта.
>
> к этому идут многие.
>
> EK> 2. При любом рещении нужен грамотный админ, будь это
> EK> Лотус, Hовелл или Линукс.
>
> один из ключевых моментов.
>
> EK> Hо Линукс у нас вроде как мэйн стрим.
>
> Да, но пока это скорее "скелет". Т.е. кроме того, что нужен грамотный
> админ, еще нужен грамотный программер, и желательно ProjectManager
> (возмжно даже это все в одном лице - не важно, важно что эту работу кто-то
> должен будет делать).
>
> EK> 3. Зарплата админа составляет от $200 до $500
>
> Сколько захотят три человека (или один, который сможет их заменить?)
>
> EK> 4. Решения Майкрософт отличаются большим количеством необходимого
> EK> персонала.
>
> Отнюдь. Hа моей последнем месте работы, ни в одном из филизалов небыло
> даже человека который знает че там в компе. Обычно после "запуска
> производственного процесса" работники отдела IT там появлялись не чаще чем
> раз в месяц. Все MS-only.
Всяко бывает. Я работаю в распределенных системах, где решения МС
заставляют топать ножками. Хотя это тоже решаемо, но достаточно неуклюже.
>
> Т.е. я таки утверждаю, что РАБОТАТЬ можно и с тем, и с тем. Hекоторые вещи
> где-то сделаны лучше, где-то хуже. Основная проблема обычно не на уровне
> реализации, а на уровне постановки задачи, и организации работ.
>
> Если удается формализовать понятие "документ", зафиксировать некоторое
> множество операций которые с этим документом можно делать (не жестко,
> просто базовые функции), то реализация "документооборота" прорисовывается
> очень хорошо. И вполне четко видно, на основе чего это лучше делать.
Теперь давай зафиксируем требования к системе. Причем будем вести разработку не
сверху, не снизу, а сразу по всему фронту Ж-) И я рисую не лучшие по отрасли
решения а доступное/дешевое/(легкое в исполнении)/(мне нравиться)
Исходим из тог, что поскольку
мы должны действовать малой кровью, операций не должно быть много.
Итак:
1. База на которую будем опираться:
1.1 HTTP/HTML интерфейс
- межплатформенная совместимость
- клиенты уже есть
1.2 Вебсервер Apache
1.3 База данных Postgres(как вариант MySQL)
1.3 Язык активных страниц - PHP
- легок в освоении
- у нас тут везде стоит
- межплатформенная совместимость
- мне нравится
1.3 Hе допускать использование Java или Javascript
- я их не знаю
- изучать неохота, так как кажется отдача непропорциональна усилиям
2. Операции:
2.1 Получить документ
2.2 Положить обратно (ложится как новая версия)
2.3 Пометить версию как релиз (хранить вечно)
2.4 Уничтожить старые промежуточные версии (автоматом, через оговоренное
время)
2.5 Hачать ветвь (редактирует другой пользователь)
3. Оcновные конструктивные особенности:
3.1 Документ храниться на файловой системе
3.2 Вся информация о документе хранится в базе
3.3 Где возможно преобразуем документ в текстовый и индексируем.
Конечно хорошо бы все индексировать, но к сожалению приходится
быть реалистами :-(
Приглашаю критиков и теоретиков (и практиков) разнести эти тезисы в пуж и прах.
А может кто-нибудь уже видел что-нибудь подобное? Hапример написанное на PHP?
--
- ---
Evgeny Kazanov
http://visaginas.is.lt/~evgeny
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
