Проектор 2.09 prevision

[ermouth]

Предыстория – http://ermouth.livejournal.com/270447.html

Сижу вот сейчас думаю над фичами, которые мне, как менеджеру проектов, были бы интересны в собственной софтинке.

1. Видимо, я добавлю возможность аттача результатов выполнения задачи прямо в задачу.

2. Внутри задач, вероятно, появятся итерации, либо я реализую это с помощью перелицовки текущей механики.

С аттачами вырисовалась забавная проблема – совсем не с той стороны, с какой я её ждал. Я полагал, что при больших аттачах – десятки и сотни мегабайт на проект в сумме – я буду иметь серьёзный lack of productivity и в работе интерфейса, и при открытии файла. Всё же файл проекта – это xml, и самая простая возможность делать аттач – это включать его в файл как base64binary-node.

Оказалось, со скоростью парса и интерфейсом никаких проблем. Файло по 200 мегов открывается всего на девять секунд дольше, чем 0,5 Мб (тот-же файл, но без аттачей). И интерфейс нифига не тормозит, хотя он real-time renderer исходного xml c помощью xsl в dhtml (папа, с кем ты сейчас говорил? :).

Это всё на обычном ноуте в режиме питания “Сбалансированный”.

Проблема вылезла с другой стороны – DOM чрезвычайно охоч до памяти. На открытие 200-мегового xml и его трансформ выжралось 900 Мб.

А у меня ещё робот сидит на сервере, который таких файлов может открыть несколько за раз. И также распарсить их MS XML-ем…

Опять же сохранение по сети таких монстров, то-сё.

В раздумьях, короче.

Comments

[ktototam-lj.livejournal.com]

На мой дилетантский взгляд, я бы инклюдил превьюшки (пусть и хай-рез, что бы можно было разглядеть детали), а файло линковал.

[ermouth.livejournal.com]

с линками не всё так просто. для того, чтобы они были consistent, файлы нужно где-то держать централизовано. да и вставлять линки очень неудобно -- надо обязательно давать сетевой путь, чтобы файл был доступен с разных машин, и сама механика вставки гиперссылок (а это гиперссылка, по сути) не очень то удобна.

превьюшки даже не стоят того, чтобы их реализовывать. гимор не сопоставим с выхлопом.

мне пока видится такая стратегия: робот на сервере, который время от времени обходит все проекторы, просто будет выкоцивать из проектора аттачи, складывать их куда надо, а вместо аттачей оставлять ссылку.

стратегия в целом очень даже цельная -- но надо много кода писать.

[ktototam-lj.livejournal.com]

Мне виделось, что при в момент аттача файло шлется роботу, он складирует куда надо и возвращает проектору ссылку. В случае, если проектор оффлайн, файло временно аттачится к нему — и дале по твоему сценарию. Превьюшки же я как раз предлагал для автономности функциональности в случае оффлайна, хотя тогда будет вероятность того, что они уже неактуальны после итерации.

[ermouth.livejournal.com]

не, моментальный сенд из сенситив ту файл сайз весьма и весьма.

[ktototam-lj.livejournal.com]

а как соседние проекторы будут сразу узнавать, что у задачи появился аттач? или это не важно?

[ermouth.livejournal.com]

абсолютно не важно )

[ktototam-lj.livejournal.com]

то есть схемы по типу — журналист написал текст, аттачнул, его тут же увидел у себя редактор, вычитал, отправил на итерацию — не предусматривается? нужно хранение финального результата?
(я, видимо, не совсем представляю схему работы, вот и теоретизирую))

[ermouth.livejournal.com]

журналисту-дизигнеру-фотографу нечего делать в проекторе )

[ktototam-lj.livejournal.com]

Да, уже сообразил. Далеко и не туда ушел ))

[mastre.livejournal.com]

у тебя вся база в xml файлах, как я понял?
а почему ты не используешь rdbms?

[ermouth.livejournal.com]

почему же не использую? использую )

[recit.livejournal.com]

Вот он, искомый формат коммуникаций :)
http://davidhorvitz.tumblr.com/post/101380835