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 размерностям.
Здесь можно остальные измерения обозначить другими атрибутами (а не
только связями) - цвет (заливки и границы), форма узлов, текстура и т.д.
По этим атрибутам можно как минимум фильтровать. По цвету - даже близкие
цвета (с заданной глубиной).

Net vs Table

Вообще, конечно, сетевое представление данных - тоже не идеал.
Оно годится для навигации по очень разнородным данным, хитро связанным между собой.
Тогда как по однородным данным лучше, всё-таки, таблица. Тут можно быстро сравнить позиции, сортировать, фильтровать. Наглядно получается.
Пример - знаменитые краны шаровые.
Выглядеть это будет так:
1. набираем в поисковой строке "кран"
2. получаем сеть, где есть все краны - шаровые и нет, для газа и жидкости, металлические и ПЭ. Рядом - связанные понятия - среда, материал, категории (арматура) - может, человек и не кран искал, а клапан.
3. и вот теперь, когда он выберет конкретный тип крана (шаровый металлический под газ) - получает таблицу всех кранов - и ряд полей для уточнения рядом: DN, PN etc - т.е. общие атрибуты для данного типа кранов
4. Он может выбрать и 2 типа оборудования - e.g. ПЭ под газ и металл под жидкость. Тогда отображаются и те и те - с общими атрибутами.
Возможно, часть поля останется с сетью - для дальнейшей навигации и чтобы быть в курсе дела, а часть - под таблицу с выбранным оборудованием.

GooglePIM start

Вот, завел новый блог - к проекту GooglePIM.
Первое приложение этого проекта - как раз работа с блогом.
GoogleAPI, конечно, рулит - потрясающе.
Еле разобрался, что куда.
В общем стартовый объект - один, назвал я его blogspot.
В нем может быть несколько блогов.
В каждом блоге - несколько постов.
Ну, и к каждому посту - несколько комментариев. На этом вложенность, слава богу, заканчивается.
На текущий момент уже получаю все блоги, посты и каменты.
Используется python и python-gdata.
Теперь это надо красиво в PyQt4 закатать - сделать дерево блогспот-блог-пост-камент.

Grouping-sorting-filtering

1. Выборка осуществляется в графическом режиме, подбором "шнуров" (т.е. ребер графа) в "шнуркомплекты". Т.е. Если надо отобрать "Краны" И "DN50" - то отбираются именно эти узлы (или ребра?) в комплект;
2. Каждый пользователь может создать свою пачку шнуркомплектов;
3. Можно создать библиотеку общих комплектов (шаблонов?);
4. схема комплектов может быть сетевой (т.е. "формула" комплекта для выборки данных из сети - сама - сеть);
5. но основная схема - неизбыточна (что я имел в виду?..).