$

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

Onpage vs client-server

Речь о том, какой вариант навигатора делать, все-таки, первым - встроенный в страницу на JS, или же клиент-серверный.
Onpage имеет то преимущество, что его можно разместить где угодно - даже на Google pages в статических страничках. За это мы имеем:
1. заморочки с JS;
2. большой и тяжелый для браузера код;
3. инсекурность данных;
4. ограничение в применяемых инструментах - т.е. _все_ программы надо носить с собой.
С другой стороный, C-S вариант требует наличия этого самого S. Зато мы не ограничены в средствах, разгружаем клиента, сохраняем know-how.
Резюме - первым бум делать вариант C-S, рендер - graphviz, исходные данные - xml, формат вывода - svg, без анимации.

n-dimention

2D-сеть для отображения - это хорошо. Но - мало.
Было бы намного презентабельней - 3D вариант.
Но этого тоже бывает мало - бывает, необходимо искать/фильтровать по
8..10..X размерностям.
Здесь можно остальные измерения обозначить другими атрибутами (а не
только связями) - цвет (заливки и границы), форма узлов, текстура и т.д.
По этим атрибутам можно как минимум фильтровать. По цвету - даже близкие
цвета (с заданной глубиной).