Где граница между PIM/DMS/GroupWare?

Имеем классику PIM:
1. Контакты
2. Задачи
3. Мыло
Еще (во многих):
4. Заметки (Notes)
и вот тут начинается интересное:
* notes бывают типа разные. Проще всего - plain-text
* которые быстро становятся richtext (с форматированием)
* который быстро перерастает в html
* или в другой формат (rtf/doc/odt/docbook (!)/иное)
* а еще документы бывают не только текстовые, но еще и типа spreadsheet
* или там media (audio/video/image)
* и вся эта хрень требует навигации
* и получается локальный себе DMS
* а потом оказывается, что этим надо бы поделиться (share)
* и получается groupware
* ...

Где начало того конца, которым кончается начало?

Starting TheStorage

Нельзя объять необъятное. Начинается с каталогов с отдельными схемами, потом пошли связи между объектами внутри каталогов, потом - между объектами разных каталогов, потом - объекты в нескольких каталогах, плюс категории... И заканчивается семавеб, которого нет. Думать можно вечно.
Выход - дорогу осилит идущий.
Сиречь - все таки сделать один продукт за раз. И - трансляторы.
Продукт будет называться скромно и со вкусом - TheStorage.
Размещаться - в code.google.com/p/semen
Там же - keyfeatures etc

$

IMHO - на этом таки можно заработать.
Подписать на нормальный сервис на божеских условиях за божеские дегни.
Like (Google Apps):
* demo - ограничено + сказки (+desktop под все платформы)
* trial - Full на X дней
* и там разные схемы - от ёмкости, скорости etc.

Ибо задалбывает всё в голове держать патамушта.

ЗЫ: а это уже катит на бизнес-план... тока хрен там - йа сам :-)

Google Gears, SyncML и всё-всё-всё

Ковыряюсь же ж с этим поделием - GooglePIM.
Каждый старт - медленная закачка по Atom (aka RSS) всех блогов, постов и каметов.
Порезал - чтобы по одному.
Всё-равно долго.
Ессно, возникает мисль кешировать это дело.
Вспомнив, что еще хотелось бы оффлайн работать (например - писать блоги в метро), возникает мисль локального кеширующего типа прокси-сервера...
Оформляются требования, продумывается архитектура... На всякий случай - попытка проверить - может уже умные люди что-то подобного сделали... И тут - шойтан! - всплывает Google Gears. Читаем спецификацию - точно! - то, что доктор прописал :-)
Но есть один нюанс (с) - он делает хороший занос хвоста, но политика синхронизации - каждый сам себе доктор.
Формируем себе ТЗ, определяем гениальный алгоритм синхронизации, учитываем все возможные засады... На всякий случай - может уже есть? Например - SyncML. Шойтан! - там уже всё прописано :-)

Ессно, возникает вопрос - а зачем было самотужки выдумывать свои решения, если есть готовые?
Спрашивали - отвечаем:
1. их - готовых - вагон и телега;
2. если сначала сам _допер_ как что надо делать - а потом это же прочитал в спецификациии - значит, а) ты правильно допер, и б) это - правильная спецификация.
3. когда до этого допрешь сам - та же спецификация читается совсем по-другому - не "и нафига этот цирк?..", а "ну ессно!".

---

синкмл синкмлом, но пока не всё так радужно.
1. SyncML очень многое оставляет на реализацию.
2. во всех 7 вариантах синхронизации сервер - активный партнер. В плане гугля последний - пассивный партнер.
3. RTM (как пример использования Gears) - штука хорошая, но они ж сам себе сервер... Активный сервер.
Вооот...

Пока что (влёт) приходят в голову только следующие варианты:
* таки да, пытаться взять на себя (сиречь - на каждое устройство) функции и кеширования, и синхронизации;
* кеширование оставить на устройстве (ессно), но сделать промежуточный сервер (GAE), реализующий SyncML-интерфейс к GData;
* иное
Для этого надо:
* поковырять Google Gears - может, расколятся, как у них там устроено?
* поковырять GData Atom - может, через Atom удастся получить _удаленные_ объекты? (это самое геморрное в этой истории).

ТЗ на JS

Цель:

создание программы на JavaScript, включаемой в статическую online-страницу, для динамической навигации по ресурсам Internet.

Прототип

Данные:

xml-файл с описанием узлов/рёбер графа. Для узлов - название, ссылка, подсказка.

Внешний вид:

на странице отображается центральный узел и ближайшие связанные с ним узлы - уровень рекурсии указывается пользователем. Каждый узел - это элемент "ссылка". Если у узла (внешнего) существуют связи с узлами за пределами текущего отображения - рядом с таким узлом появляется элемент +. При нажатии на сам узел происходит переход на его URL. ПРи нажатии на + - узел оказывается в центре нового графа - со всеми вытекающими.
Размещение элементов - по алгоритму DirectGraph, но может быть изменено пользователем.

Поведение

Смена одного графа на другой - с анимацией, алгоритм которой можно будет изменять:

• Удаляемые узлы - остаются на месте и постепенно исчезают;
  
• Новые узлы - постепенно проявляются на своих местах;
  
• Остающиеся узлы - двигаются от старых координат к новым
  

Рёбра двигаются за узлами. Перемещение от начального состояния к конечному - за конечное же время. Физика перемещения может быть в дальнейшем заменена.

Т.о. выделяются модули, которые можно будет в дальнейшем заменять:

• data (источник данных - файл, внешний ресурс)
  
• layout (алгоритм размещения узлов)
  
• animation (алгоритм анимации)
  
• view (метод отображения - html/svg/canvas)
  

Standalone (AKA OnPage) dynamic graph

An idea is - to make 1 (one) js + 1 (one) graphml data, that:

• Prototype


• dynamic from-to


• Functions:
  
  
  
  • Standalone expand/collapse
  
  
  • Customed speed
  
  
  • Customed recurse level
  
  
  • Customed Layout
  
  
  
  


• Technologies:
  
  
  
  • use pure HTML (div + position)
  
  
  • Runge-Kutta lines
  
  
  
  

Pure HTML graphics

Окаааазывается!
Можно рисовать графику (по крайней мере ту, что нас интересует - графы) на чистокровном HTML!
Без svg, flash, canvas и т.д.!
Показываю (в левом верхнем углу (100x100px) должно появиться сцылко node0, текст node1 и цепочка между ними):

node0

node1