Стартовая страница

# Andrew Lobanov to mirage @ Re: Протокол IDEC @ idec.talks 09/10/18 17:32

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



# mirage to Andrew Lobanov @ Re: Протокол IDEC @ idec.talks 09/10/18 20:17

mirage>>>> | GET /x/с/<параметры>
mirage>>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
AL> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.

Эха содержит список id сообщений. Если новые id добавляются только в конец,
то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
Только возникнет проблема если это сообщение будет удалено.

Другой вариант при запросе методом инкрементного листинга нода может записывать в файл эхи метку вида ">node_name"
и при следующем запросе отдавать список от этой метки и двигать ее в конец.

Я больше склоняюсь к первому варианту, он более гибкий, простой и стабильный.
Надо только продумать удаление, без удаления id сообщения из списка.

+++ Caesium/0.4 RC1