Пробуем raw http

Идея была такая - а что, если python-gdata делает, больше, чем просят? В смысле - запрашивает.
План работы:
1. написать приложение, которое, пользуясь _чистым_ http сделает те же запросы (ну и вообще полезно для отладки).
2. сравнить результаты.
Сделал. Python+httplib+urllib. По дороге научился получать у гугля ключи от хаты (токен авторизации) - классная вещь.
Результаты: не отличаются НИЧЕМ :-(
gdata отдал 20KB (оформлено - с ns и всё такое), raw http - 19KB неоформленного xml.
Информация - та же.
Вывод - чудо не произошло.
Остался последний патрон: Atom feed history spec (RFC 5005).
ЗЫ: ну не может быть чуда нед! Гугль даже пишет журнал _всех_ запросов! О чем прямо сказано в Google API - "указывайте приложение, каким просите - надо для истории".

GooglePIM reloaded

Мда, забросил я было это дело...
А тут недавно обнаружил, что гугель уже прикрутил Todo в свою балалайку.
Это то, чего не хватало.
Вот теперь можно лепить полноценный ПИМ. Или Гугль-десктоп :-)

В прошлой серии тормознулось из-за того, что при каждом старте софтины надо снимать _всю_ ленту Atom. Т.е. прокачиват сотни метров.
Идея появилась - сделать прокладку в виде SyncML. Но это ж кто её будет делать...
Поэтому сейчас сделаем проще (образно) и хитрее - воспользуемся возможностями сомого gdata.

Общая идея в том, чтобы не качать лишнего.
Для этого:
1. все данные надо кешировать
2. все изменения - журналировать и выполнять оптом (ессно, с проверкой - вдруг кто-то что-то там во время редактирования изменил.

Что для этого надо?
1. хранить последнее updated фида
2. хранить времена updated всех элементов
3. в случае изменения updated фида:
3.1. снять все элементы, у которых update >= feed update (ркурсивно повторить 2+)
3.2. причем не полностью элементы, а только id и updated
3.3. снять все _deleted_ элементы на тех же условиях.
4. снимать элементы небольшими порциями

Да, локально будет храниться полная копия всех элементов. А шо рабиць?
Еще прийдется разруливать конфликты, паче они случатся.
Зато можно поработать offline - и опубликовать в гугле одной педалькой.
В batch-режиме
Локальной базой можно сделать BerkleyDB или SQLite.

Итого план работы:
1. изучить возможности п.п. 3.2 и 3.3
2. разработать алгоритм синхронизации
3. разработать формат базы

Полетели.

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 удастся получить _удаленные_ объекты? (это самое геморрное в этой истории).

GooglePIM start

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