Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет kouzdra ([info]kouzdra) в [info]ljr_dev
@ 2005-07-24 16:00:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Я сейчас с подачи [info]yushi@lj переписываю lj-gate. Что делаю -
помимо "причесывания" кода, пересаживаю его на syncitems, там
все можно сделать куда корректнее, чем сейчас, в частности -
update и delete там явно отличатся от create. И, безусловно, надо выкидывать
этот страх с -10 минут, а просто запоминать в базе
время последней синхронизации, отданное syncitems (он отдает именно
реальное время события, а не дату для постинга) и от него
и плясать в следующий раз.

Единственный вопрос - что делать с новыми пользователями - можно либо
стартовать от текущей даты, либо копировать дневник с самого начала.
Второе, наверное, не очень хорошо, хотя можно сделать параметром.

Сейчас я вынужден уехать на несколько дней - так что, если не горит,
- не трогайте его сильно.


(Добавить комментарий)


[info]yushi
2005-07-25 23:41 (ссылка)
переписываю lj-gate

Прежде всего — спасибо!

пересаживаю его на syncitems

А чем так хорош syncitems при наличии getevents с selecttype, равным "syncitems" (который, собственно, и используется)? Вон, даже сами авторы описания протокола пишут:

For journal entries (type "L"), use the getevents mode with a selecttype of "syncitems".


update и delete там явно отличатся от create.

Ой. "Где?"©

Т.е. я действительно не очень понял, что имеется в виду. Если работа гейта с постингами через клиентский API, то обновление существующей записи и так отличается от создания новой. Если про то, что возвращает вызов syncitems, то, во-первых, там нет никакого delete, а во-вторых, он довольно бессмысленен при наличии у возвращаемого getevents поля revnum. Опять же, сами разработчики признаются:

This field isn't too useful, but you may want to make your client verbose and tell the user what it's doing. For example, "Downloading entry 5 of 17: Updated".


либо копировать дневник с самого начала

Копировать дневник в любом случае не стоит, для этого лучше написать отдельную программу.

Сейчас я вынужден уехать на несколько дней - так что, если не горит,
- не трогайте его сильно.


Разумеется. К счастью, объём кода пока такой, что "сильно тронуть" практически эквивалентно "переписать с нуля". =) А вообще пора начинать использовать CVS, конечно.

(Ответить) (Ветвь дискуссии)


(Анонимно)
2005-07-28 00:09 (ссылка)
syncitems не отдает самих items, он отдает события, происходившие с дневником после заданного момента - вот как это выглядит -
[
{
'time' => '2005-07-20 15:48:08',
'item' => 'L-2',
'action' => 'create'
},
{
'time' => '2005-07-20 15:57:56',
'item' => 'L-3',
'action' => 'create'
},
{
'time' => '2005-07-20 15:58:13',
'item' => 'L-4',
'action' => 'create'
},
{
'time' => '2005-07-23 23:11:47',
'item' => 'L-5',
'action' => 'update'
},
{
'time' => '2005-07-23 23:12:52',
'item' => 'L-6',
'action' => 'create'
},
{
'time' => '2005-07-24 14:24:40',
'item' => 'C-5',
'action' => 'update'
}
];
(для delete тоже есть сообщение - проверял, работает). Потом уже с этим надо разбираться и брать getevents нужные сообщения и делать с ними то, что сказано.

вот (http://oops.tepkom.ru/~msk/Misc/rlj2lj.pl) недопереписанный текст скрипта (я только что приехал, еще ничего не делал), он копирует весь дневник (и обрабатывает 'delete' actions). Надо его привести в порядок и научить делать это инкрементально. От момента предыдущего обновления. Если попрет - попробую завтра успеть (завтра вечером я опять уезжаю. до где-то понедельника).

(Ответить) (Уровень выше)


[info]kouzdra
2005-07-28 00:43 (ссылка)


разработчики признаются:

This field isn't too useful, but you may want to make your client verbose and tell the user what it's doing. For example, "Downloading entry 5 of 17: Updated".


Понял - на самом деле оно там есть. action=delete. Насколько надежно - в свете этого коммента не берусь сказать (не обратил внимания), но у меня все работало.

Кроме того, что более важно - syncitems отдает дату последнего изменения с точки зрения hosta (равно как и реальные даты событий, а не то, что у них прописано в date). То есть - дату, которую надо давать следующему запросу для получения новой порции истории.

(Ответить) (Уровень выше)

Я его тронула
[info]zmey
2005-07-25 23:46 (ссылка)
Не вполне сообразив, что [info]yushi@lj уже послал код, я его "потрогала".
Правда, все мои правки были в bml-ях и касались главным образом очеловечивания интерфейса.

Так что если вы основным кодом занимались, то всё в порядке, наверное.

(Ответить) (Ветвь дискуссии)

Re: Я его тронула
[info]kaledin
2005-07-27 06:04 (ссылка)
Слушай, а вы не хотите распознавать пользователя LJR средствами LJR? т.е. если он загружен, спросить у системы и подставить username?

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Я его тронула
[info]zmey
2005-07-27 12:30 (ссылка)
Раньше не хотели.
Теперь, наверное, хотим. Раз уж всё равно его в код интегрировать придётся.

(Ответить) (Уровень выше)

Re: Я его тронула
[info]kouzdra
2005-07-28 00:44 (ссылка)
Вообще-то, конечно, чукча думает, cvs тут надо :)

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Я его тронула
[info]zmey
2005-07-28 01:25 (ссылка)
Стопудово.

(Ответить) (Уровень выше)


[info]yushi
2005-07-26 02:10 (ссылка)
И, безусловно, надо выкидывать
этот страх с -10 минут, а просто запоминать в базе
время последней синхронизации, отданное syncitems


Вот в этом вы абсолютно правы!

Причём — для каждого конкретного пользователя, а то уже возникают проблемы.

(Ответить)