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

# mirage to All @ Протокол IDEC @ idec.talks 09/10/18 15:54

Читаю про сабж и не понимаю.

| GET /x/с/<параметры>
| Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.

Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.


| /u/m/msgid/msgid/msgid

Количество msgid лимитировано длиной GET запроса на сервере.
Почему вместо этого не передавать msgid в POST?

+++ Caesium/0.4 RC1



# Peter to mirage @ Re: Протокол IDEC @ idec.talks 09/10/18 16:05

mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?

Думаю, из соображений простоты. А фетчеры обычно забирают сообщения пачками, скажем, по 16 сообщений. В цикле. Поэтому ограничение не критично.



# vit01 to mirage @ Re: Протокол IDEC @ idec.talks 09/10/18 16:33

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