Ну вот...
Замучила совесть вконец - человеку ж обещал поработать надо темой - а сам закинул, цуко... Не от хорошей жизни, а от работы - но тем не менее...
Сегодня бортанул все халтуры и немного поработал с 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 возмет на себя - а мне отдаст в чистом виде.
воскресенье, 24 января 2010 г.
среда, 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.
Ибо задалбывает всё в голове держать патамушта.
ЗЫ: а это уже катит на бизнес-план... тока хрен там - йа сам :-)
воскресенье, 9 ноября 2008 г.
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 удастся получить _удаленные_ объекты? (это самое геморрное в этой истории).
Каждый старт - медленная закачка по Atom (aka RSS) всех блогов, постов и каметов.
Порезал - чтобы по одному.
Всё-равно долго.
Ессно, возникает мисль кешировать это дело.
Вспомнив, что еще хотелось бы оффлайн работать (например - писать блоги в метро), возникает мисль локального кеширующего типа прокси-сервера...
Оформляются требования, продумывается архитектура... На всякий случай - попытка проверить - может уже умные люди что-то подобного сделали... И тут - шойтан! - всплывает Google Gears. Читаем спецификацию - точно! - то, что доктор прописал :-)
Но есть один нюанс (с) - он делает хороший занос хвоста, но политика синхронизации - каждый сам себе доктор.
Формируем себе ТЗ, определяем гениальный алгоритм синхронизации, учитываем все возможные засады... На всякий случай - может уже есть? Например - SyncML. Шойтан! - там уже всё прописано :-)
Ессно, возникает вопрос - а зачем было самотужки выдумывать свои решения, если есть готовые?
Спрашивали - отвечаем:
1. их - готовых - вагон и телега;
2. если сначала сам _допер_ как что надо делать - а потом это же прочитал в спецификациии - значит, а) ты правильно допер, и б) это - правильная спецификация.
3. когда до этого допрешь сам - та же спецификация читается совсем по-другому - не "и нафига этот цирк?..", а "ну ессно!".
синкмл синкмлом, но пока не всё так радужно.
1. SyncML очень многое оставляет на реализацию.
2. во всех 7 вариантах синхронизации сервер - активный партнер. В плане гугля последний - пассивный партнер.
3. RTM (как пример использования Gears) - штука хорошая, но они ж сам себе сервер... Активный сервер.
Вооот...
Пока что (влёт) приходят в голову только следующие варианты:
* таки да, пытаться взять на себя (сиречь - на каждое устройство) функции и кеширования, и синхронизации;
* кеширование оставить на устройстве (ессно), но сделать промежуточный сервер (GAE), реализующий SyncML-интерфейс к GData;
* иное
Для этого надо:
* поковырять Google Gears - может, расколятся, как у них там устроено?
* поковырять GData Atom - может, через Atom удастся получить _удаленные_ объекты? (это самое геморрное в этой истории).
Подписаться на:
Сообщения (Atom)