subject: Протокол IDEC
09.10.2018 18:54
mirage (syscall,44)
Читаю про сабж и не понимаю.
| GET /x/с/<параметры>
| Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
| /u/m/msgid/msgid/msgid
Количество msgid лимитировано длиной GET запроса на сервере.
Почему вместо этого не передавать msgid в POST?
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
09.10.2018 19:05
Peter (syscall,1) => 4ilcAaoUoz9OHWEMcUUS
mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?
Думаю, из соображений простоты. А фетчеры обычно забирают сообщения пачками, скажем, по 16 сообщений. В цикле. Поэтому ограничение не критично.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
09.10.2018 19:33
vit01 (mira, 1) => 4ilcAaoUoz9OHWEMcUUS
mirage> | GET /x/с/<параметры>
mirage> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
// удалять сообщения может только держатель ноды, и это в будущем так и останется
mirage> | /u/m/msgid/msgid/msgid
mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?
С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
09.10.2018 19:54
mirage (syscall,44) => SL9AJzzwuJ8Njst52A13
mirage>> | GET /x/с/<параметры>
mirage>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
Тогда это уже не количество сообщений будет, а что-то другое.
vit01> // удалять сообщения может только держатель ноды, и это в будущем так и останется
mirage>> | /u/m/msgid/msgid/msgid
mirage>> Количество msgid лимитировано длиной GET запроса на сервере.
mirage>> Почему вместо этого не передавать msgid в POST?
vit01> С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
vit01> Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.
Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
09.10.2018 20:32
Andrew Lobanov (tavern,1) => qHTH1FvNJHW4vhLZJDLO
mirage>>> | GET /x/с/<параметры>
mirage>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.
На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
vit01>> С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
vit01>> Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.
Я задумывался, но реальной пользы не заметил.
mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
iitxt это ii-клиент, что следует из названия. Даже если POST u/m будет в IDEC добавлен, в iitxt никто не будет ничего менять =)
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
09.10.2018 23:17
mirage (syscall,44) => wf9LpXpn29pB5nYpCE6E
mirage>>>> | GET /x/с/<параметры>
mirage>>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
AL> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
Эха содержит список id сообщений. Если новые id добавляются только в конец,
то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
Только возникнет проблема если это сообщение будет удалено.
Другой вариант при запросе методом инкрементного листинга нода может записывать в файл эхи метку вида ">node_name"
и при следующем запросе отдавать список от этой метки и двигать ее в конец.
Я больше склоняюсь к первому варианту, он более гибкий, простой и стабильный.
Надо только продумать удаление, без удаления id сообщения из списка.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 05:43
Andrew Lobanov (tavern,1) => nTbFBdG3cWLUf0uLIWxW
AL>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage> Только возникнет проблема если это сообщение будет удалено.
А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 06:36
mirage (syscall,44) => G6K6qSYLTuSXj1mkzrU5
AL>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
AL> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
Несколько десятков ID и получит. Только новое.
Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
На ноду еще приходят сообщения: ID4 ID5 ID6.
В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
И получает ID4 ID5 ID6 и запоминает ID6.
Весь индекс тянуть заново не надо.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 07:48
mirage (syscall,44) => mzu2V8Iz3VIAVeDg0TOi
AL>>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>>> Только возникнет проблема если это сообщение будет удалено.
AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.
mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.
Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 08:15
Peter (syscall,1) => mzu2V8Iz3VIAVeDg0TOi
> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 08:43
Andrew Lobanov (tavern,1) => mzu2V8Iz3VIAVeDg0TOi
AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.
Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?
mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.
Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 08:43
Andrew Lobanov (tavern,1) => BbIPPz2vHZG9XPqhBkvj
mirage> Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.
Как ты это видишь в текущем варианте? Как из ID получить что-то типа -10:10?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 08:43
Andrew Lobanov (tavern,1) => a86auQjs1wYzGMdvp7k2
>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 09:01
mirage (syscall,44) => RfJ3ngmvZ5jBwedEHnHN
AL>>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage>> Несколько десятков ID и получит. Только новое.
AL> Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?
Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Допустим это 100 idшников.
Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
1. Придет меньше 100 id - запоминаем последний, конец.
2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
mirage>> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage>> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage>> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage>> И получает ID4 ID5 ID6 и запоминает ID6.
mirage>> Весь индекс тянуть заново не надо.
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 09:01
mirage (syscall,44) => JNN6hzvQjrmMDtavn4kz
>>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter>> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
AL> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах
и время обработки запроса. С ID проще, строже.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 09:23
Andrew Lobanov (tavern,1) => IivXLbeTBZdnaUDTNUfl
mirage> Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Сколько угодно =)
mirage> Допустим это 100 idшников.
mirage> Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
mirage> 1. Придет меньше 100 id - запоминаем последний, конец.
mirage> 2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
Этот вариант мы тоже рассматривали. Но пока думали как это сделать так, чтобы не плодить сущностей и не сломать совместимость с ii (ты до сих пор можешь взять ii-client-03 и пользоваться им), соорудили эту штуку на том, что было. Получилось просто и без излишеств.
AL>> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
mirage> Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.
Я понимаю, что предложение, но не понимаю в чём будет выигрыш? Можно и аутбаунды сделать а-ля FTN, но пользы нет.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 09:23
Andrew Lobanov (tavern,1) => lstoN4AEjZnjdfF4lZZc
AL>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
Ещё проще так, как есть. Потому что оно уже есть и оно простое.
Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 09:15
mirage (syscall,44) => RfJ3ngmvZ5jBwedEHnHN
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
По нетмайлу готов proposal. Просто чтобы внимание не распылять по одной теме пишу :)
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 10:08
mirage (syscall,44) => vrtvwQveGFzZsKJ60Arv
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Решаемая задача: скачать обновление индекса.
Предложеное решение: запросить все что после конкретного ID.
Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
Получается, если надо качать все обновление индекса за раз, то один запрос.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 10:19
mirage (syscall,44) => vrtvwQveGFzZsKJ60Arv
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Этот x/c нужен же для u/e?
Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 10:51
Andrew Lobanov (tavern,1) => bB5P388RPK4Tguw7ML8x
mirage> Решаемая задача: скачать обновление индекса.
mirage> Предложеное решение: запросить все что после конкретного ID.
mirage> Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
mirage> Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
mirage> Получается, если надо качать все обновление индекса за раз, то один запрос.
Можешь предложить красивое решение?
Вот, например, я подписан на несколько эх. Тогда я просто отправляю запрос x/c/bash.rss/pipe.2032/idec.talks и потом делаю u/e/bash.rss/pipe.2032/idec.talks/-50:50. Передавать что-то типа x/e/bash.rss/<id1>/pipe.2032/<id2>/idec.talks/<id3>?
Я ничего не вижу плохого в более других вариантах, если это будет нужно кому-то. Но пока я не вижу кому и зачем может быть нужно то, что ты предлагаешь. Какую практическую проблему ты пыташься решить?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
10.10.2018 10:51
Andrew Lobanov (tavern,1) => dG7h6emrXl3vR0z3AU9B
mirage> Этот x/c нужен же для u/e?
Нет.
mirage> Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
mirage> Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
Да, но зато никакой дополнительной нагрузки на ноду.
mirage> А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
Несколько килобайт (это в худшем случае) лишней информации без переписывания ноды. И узлу не придётся шерстить толстые инндексы на каждый чих.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
11.10.2018 20:44
vit01 (mira, 1) => qHTH1FvNJHW4vhLZJDLO
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.
Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage> Только возникнет проблема если это сообщение будет удалено.
Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
12.10.2018 14:06
Andrew Lobanov (tavern,1) => yrMuLB0ciAnxucjyAt2w
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
vit01> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
mirage>> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
vit01> Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
vit01> iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
vit01> Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.
Да все эти варианты мы уже рассматривали и обсуждали. Начиная с лета 2014 и заканчивая обсуждением расширенной u/e. Пройденный этап, откинутые варианты. Нет смысла к ним возвращаться. К тому же до сих пор не было озвучено предполагаемых преимуществ перед текущим вариантом.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Протокол IDEC
12.10.2018 17:18
vit01 (mira, 1) => jwKw1rVPAehlRQQvKLZU
vit01>>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
vit01>> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
AL> Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
Действительно, тут я ошибся. IDEC Mobile тоже подсчитывает слайсы по ним (хоть и более хитро), а ещё уведомления выдаёт :)
Важно, что поле только возрастает, и что на сервере после удаления сообщений значение /x/c не должно уменьшаться.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
--------------------------------------------------------------------------------