Идея была такая - а что, если python-gdata делает, больше, чем просят? В смысле - запрашивает.
План работы:
1. написать приложение, которое, пользуясь _чистым_ http сделает те же запросы (ну и вообще полезно для отладки).
2. сравнить результаты.
Сделал. Python+httplib+urllib. По дороге научился получать у гугля ключи от хаты (токен авторизации) - классная вещь.
Результаты: не отличаются НИЧЕМ :-(
gdata отдал 20KB (оформлено - с ns и всё такое), raw http - 19KB неоформленного xml.
Информация - та же.
Вывод - чудо не произошло.
Остался последний патрон: Atom feed history spec (RFC 5005).
ЗЫ: ну не может быть чуда нед! Гугль даже пишет журнал _всех_ запросов! О чем прямо сказано в Google API - "указывайте приложение, каким просите - надо для истории".
среда, 3 февраля 2010 г.
воскресенье, 24 января 2010 г.
GooglePIM alive
Ну вот...
Замучила совесть вконец - человеку ж обещал поработать надо темой - а сам закинул, цуко... Не от хорошей жизни, а от работы - но тем не менее...
Сегодня бортанул все халтуры и немного поработал с GData.
Вопрос был простой: как-то обеспечить синхронизацию локальных данных с гуглем.
Для этого надо знать - что с последнего запроса:
1. удалено
2. добавлено
3. изменено
Ну, с 3) проблем больших нет - нам бы только узнать, что изменилось, а подробности уже получим, когда наступим на это дело. GData такую информацию отдает (в смысле - можно попросить прислать "updated с...").
С 2) тоже не проблема - как 3), только "published с ...".
А вот с 1) - полная засада. Т.е. гугль просто не скажет, что удалено. Удаляется с концами. Единственное исключение - Контакты - они помечаются deleted и живут так ровно 1 мес (если спецом не удалить вообще).
Итого родился алгоритм - спросить гугля пачкой сразу:
1. спросить - сколько элементов вообще (эта цифра ничего не значит еще).
2. спросить - сколько появилось новых (вот в этом месте мы уже будем знать - сколько удалено; хотя, к сожалению, не будем знать - кто - придется шерстить всех, цуко!).
3. и кто изменился.
Для этого сегодня был проведен эксперимент: сколько и каких данных отдаст гугль по простейшим запросам типа "кагдила".
Тестировал на своем блогспоте (справка - блогспотом я называю точку входа в блоггер, откуда можно узнать линки на все свои блоги (у меня их - 12), оттуда - на посты, оттуда - на каменты; т.е. блогспот - это корень блоггера (для данного юзверя)).
Есть 2 новости - плохая и как всегда.
Плохая - если гуглю ничего не сказать, то по запросу к блогспоту он отдаст:
1. кол-во блогов (это хорошо)
2. updated будет равно времени запроса (это плохо) - а не времени updated хоть одного блога (или времени удаления... короче - времени изменения состояния блогспота);
3. и, цуко, все блоги - с id, линками, названиями, тегами и прочей муйней.
Итого 12 блогов мне обошлись в 20KB. Не бог весть что - но тоже ж жалко... Это только блоги. Контактов, я думаю, отдаст на все 100 кил. Один пук - и 100 кил коту под хвост. С мобилы, ога...
Хорошая новость в том, что можно попросить ?max_results=0 - и гугль отдаст только голову - кол-во блогов (если попросить - то кол-во богов, соответсвующих критерию (updated, published).
Получилось 1KB. Тоже не фонтан - но не 20 же ж!
Теперь - к следующему уроку приготовить:
* попробовать получить блогспот не через python-gdata (может это он гонит - слишком заносит хвост клеенту и берет то, что не просили), а напрямую по atom (только надо разобраться с авторизацией - гугль же хрен отдаст просто так - за что и уважаю).
* Попробовать сделать batch-запрос - итого+published+updated.
* попросить Деда Мороза прислать мне инфу - как попросить гугль отдать только entry id вместо всего entry. Тогда я бы просто получил список id обновленных и новых entries, пометил в своей базе, что они - несвежие, а разбирался бы потом. А самое главное - сразу бы удалил несуществующие.
Еще надо бы внимательнее почитать http://code.google.com/p/libgcal/ - там есть упоминание о некоем fastsync (хотя в чЮдеса не верится).
PS. Но вообще прямо в руки лезет идея промежуточного сервера, который всю эту мороку с rss возмет на себя - а мне отдаст в чистом виде.
Замучила совесть вконец - человеку ж обещал поработать надо темой - а сам закинул, цуко... Не от хорошей жизни, а от работы - но тем не менее...
Сегодня бортанул все халтуры и немного поработал с GData.
Вопрос был простой: как-то обеспечить синхронизацию локальных данных с гуглем.
Для этого надо знать - что с последнего запроса:
1. удалено
2. добавлено
3. изменено
Ну, с 3) проблем больших нет - нам бы только узнать, что изменилось, а подробности уже получим, когда наступим на это дело. GData такую информацию отдает (в смысле - можно попросить прислать "updated с...").
С 2) тоже не проблема - как 3), только "published с ...".
А вот с 1) - полная засада. Т.е. гугль просто не скажет, что удалено. Удаляется с концами. Единственное исключение - Контакты - они помечаются deleted и живут так ровно 1 мес (если спецом не удалить вообще).
Итого родился алгоритм - спросить гугля пачкой сразу:
1. спросить - сколько элементов вообще (эта цифра ничего не значит еще).
2. спросить - сколько появилось новых (вот в этом месте мы уже будем знать - сколько удалено; хотя, к сожалению, не будем знать - кто - придется шерстить всех, цуко!).
3. и кто изменился.
Для этого сегодня был проведен эксперимент: сколько и каких данных отдаст гугль по простейшим запросам типа "кагдила".
Тестировал на своем блогспоте (справка - блогспотом я называю точку входа в блоггер, откуда можно узнать линки на все свои блоги (у меня их - 12), оттуда - на посты, оттуда - на каменты; т.е. блогспот - это корень блоггера (для данного юзверя)).
Есть 2 новости - плохая и как всегда.
Плохая - если гуглю ничего не сказать, то по запросу к блогспоту он отдаст:
1. кол-во блогов (это хорошо)
2. updated будет равно времени запроса (это плохо) - а не времени updated хоть одного блога (или времени удаления... короче - времени изменения состояния блогспота);
3. и, цуко, все блоги - с id, линками, названиями, тегами и прочей муйней.
Итого 12 блогов мне обошлись в 20KB. Не бог весть что - но тоже ж жалко... Это только блоги. Контактов, я думаю, отдаст на все 100 кил. Один пук - и 100 кил коту под хвост. С мобилы, ога...
Хорошая новость в том, что можно попросить ?max_results=0 - и гугль отдаст только голову - кол-во блогов (если попросить - то кол-во богов, соответсвующих критерию (updated, published).
Получилось 1KB. Тоже не фонтан - но не 20 же ж!
Теперь - к следующему уроку приготовить:
* попробовать получить блогспот не через python-gdata (может это он гонит - слишком заносит хвост клеенту и берет то, что не просили), а напрямую по atom (только надо разобраться с авторизацией - гугль же хрен отдаст просто так - за что и уважаю).
* Попробовать сделать batch-запрос - итого+published+updated.
* попросить Деда Мороза прислать мне инфу - как попросить гугль отдать только entry id вместо всего entry. Тогда я бы просто получил список id обновленных и новых entries, пометил в своей базе, что они - несвежие, а разбирался бы потом. А самое главное - сразу бы удалил несуществующие.
Еще надо бы внимательнее почитать http://code.google.com/p/libgcal/ - там есть упоминание о некоем fastsync (хотя в чЮдеса не верится).
PS. Но вообще прямо в руки лезет идея промежуточного сервера, который всю эту мороку с rss возмет на себя - а мне отдаст в чистом виде.
среда, 7 октября 2009 г.
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. разработать формат базы
Полетели.
А тут недавно обнаружил, что гугель уже прикрутил 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. разработать формат базы
Полетели.
воскресенье, 17 мая 2009 г.
FeelingSensitivity
Идея - чтобы система была чувствительна к настроению хозяина. Хуже - "угадывало" его желания.
Пример - пришел домой, хочется музыки. Какой - хез, её много, выбирать - влом.
Система, базируясь на статистике, биоритмах, состоянии расчетного счета etc - грит:
С: хозяин - может это?
Х: не...
С: это?
Х: не!
С: (так... хозяин не в духе... пора думать) Хозяин, приложите руку к сенсору - мы попробуем погадать.
(дальше вычисляется давление, пульс, дыхание, потение etc.)
С: Хозяин, у Вас фигня какая-то... Дыхните в трубочку, плиз.
(хозяин дишит)
С: Кхм... Вроде и пил немного... Хозяин - а посмотрите в камеру своим хлебальцем!
(хозяин смотрит в уеб-камеру)
С: Мдымс... Хозяин, у вас показатели в норме, пили Вы немного, но - судя по выражению Вашего хлебала, у Вас - мегадепрессняк. Предлагаю Rainbow'74, потом - PinkFloyd "The Wall" - и вызвать девочек.
Если Вам что-то посреди дороги не понраится - убейте меня апстену - данная информация поступит в статистику и будет учтена в следующий раз.
Пример - пришел домой, хочется музыки. Какой - хез, её много, выбирать - влом.
Система, базируясь на статистике, биоритмах, состоянии расчетного счета etc - грит:
С: хозяин - может это?
Х: не...
С: это?
Х: не!
С: (так... хозяин не в духе... пора думать) Хозяин, приложите руку к сенсору - мы попробуем погадать.
(дальше вычисляется давление, пульс, дыхание, потение etc.)
С: Хозяин, у Вас фигня какая-то... Дыхните в трубочку, плиз.
(хозяин дишит)
С: Кхм... Вроде и пил немного... Хозяин - а посмотрите в камеру своим хлебальцем!
(хозяин смотрит в уеб-камеру)
С: Мдымс... Хозяин, у вас показатели в норме, пили Вы немного, но - судя по выражению Вашего хлебала, у Вас - мегадепрессняк. Предлагаю Rainbow'74, потом - PinkFloyd "The Wall" - и вызвать девочек.
Если Вам что-то посреди дороги не понраится - убейте меня апстену - данная информация поступит в статистику и будет учтена в следующий раз.
вторник, 31 марта 2009 г.
Где граница между 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
* ...
Где начало того конца, которым кончается начало?
1. Контакты
2. Задачи
3. Мыло
Еще (во многих):
4. Заметки (Notes)
и вот тут начинается интересное:
* notes бывают типа разные. Проще всего - plain-text
* которые быстро становятся richtext (с форматированием)
* который быстро перерастает в html
* или в другой формат (rtf/doc/odt/docbook (!)/иное)
* а еще документы бывают не только текстовые, но еще и типа spreadsheet
* или там media (audio/video/image)
* и вся эта хрень требует навигации
* и получается локальный себе DMS
* а потом оказывается, что этим надо бы поделиться (share)
* и получается groupware
* ...
Где начало того конца, которым кончается начало?
воскресенье, 1 марта 2009 г.
Starting TheStorage
Нельзя объять необъятное. Начинается с каталогов с отдельными схемами, потом пошли связи между объектами внутри каталогов, потом - между объектами разных каталогов, потом - объекты в нескольких каталогах, плюс категории... И заканчивается семавеб, которого нет. Думать можно вечно.
Выход - дорогу осилит идущий.
Сиречь - все таки сделать один продукт за раз. И - трансляторы.
Продукт будет называться скромно и со вкусом - TheStorage.
Размещаться - в code.google.com/p/semen
Там же - keyfeatures etc
Выход - дорогу осилит идущий.
Сиречь - все таки сделать один продукт за раз. И - трансляторы.
Продукт будет называться скромно и со вкусом - TheStorage.
Размещаться - в code.google.com/p/semen
Там же - keyfeatures etc
понедельник, 12 января 2009 г.
$
IMHO - на этом таки можно заработать.
Подписать на нормальный сервис на божеских условиях за божеские дегни.
Like (Google Apps):
* demo - ограничено + сказки (+desktop под все платформы)
* trial - Full на X дней
* и там разные схемы - от ёмкости, скорости etc.
Ибо задалбывает всё в голове держать патамушта.
ЗЫ: а это уже катит на бизнес-план... тока хрен там - йа сам :-)
Подписать на нормальный сервис на божеских условиях за божеские дегни.
Like (Google Apps):
* demo - ограничено + сказки (+desktop под все платформы)
* trial - Full на X дней
* и там разные схемы - от ёмкости, скорости etc.
Ибо задалбывает всё в голове держать патамушта.
ЗЫ: а это уже катит на бизнес-план... тока хрен там - йа сам :-)
Подписаться на:
Сообщения (Atom)