Я после всех этих обсуждений засомневался, а может быть и правда нам нужны множественные слайсы в u/e? Может быть это нужно для адаптивного фетча? Поговорил с Андреем и стало понятно что вроде бы не нужны.

# Идея

Идея, на самом деле, простая. Мы сканируем последние сообщения станции но ровно до тех пор, пока сами не решим - хватит или нет. А решение принимаем на основе анализа полученных msgid (есть они в базе у нас или нет?). В этом отличие от просто фетча последних n сообщений.

# Алгоритм

1. Выбрали N=16, LIM=16
2. Выбрали набор эх elist: echo.1, echo.2, ... echo.i
3. Сделали запрос /u/e/echo.1...echo.i/-N:LIM
4. Для каждой эхи в ответе:
- Все отсутствующие msgid добавляем в список, который добавляем в голову msgids
- Если таких сообщений нет или ответ содержит меньше записей чем N (выгребли всё)
удаляем эху из набора elist
5. Набор elist пуст? Да! иди на 10
6. LIM=N, N = N * 2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос(ы) /u/m для всех id из списка msgids

Числа 16 и 1024 тоже эвристические. 1024 - просто способ закончить фетч если мы видим, что адаптивный фетч всё никак не дойдёт до "дна".

# Можно ли проще?

Моя станция работает по-другому. Основное отличие в том, что я делаю запросы -N:1 а не -N:LIM и просто проверяю -- а есть ли у меня это сообщение или нет? Если есть, потом я делаю фетч на -N:N.

1. Выбрали N=16
2. Выбрали эху
3. Сделали запрос /u/e/echo/-N:1
4. Сообщение есть? Или такое же как в прошлый раз? На 10
5. N = N*2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос /u/e/echo/-N:N
11. Делаем запрос /u/m для всех id из ответа пп.10 которых у нас нет

Это немного упрощает алгоритм и, возможно?, делает ситуацию безопасней, если во время сканирования добавились новые сообщения, но я работаю только с одной эхой. Если такую штуку делать со многими эхами сразу то:
a) понадобятся множественные slice
b) алгоритм станет сложнее, а не проще

Но, конечно, можно брать просто максимальный N для всех эх а потом делать один общий фетч.

1. Выбрали N=16
2. Выбрали набор эх elist: echo.1, echo.2, ... echo.i
3. Сделали запрос /u/e/echo.1...echo.i/-N:1
4. Для каждой эхи в ответе:
- Если сообщение есть или получили тот же id что в прошлый раз, удаляем эху из набора
5. Набор elist пуст? Да! иди на 10
6. N = N * 2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос(ы) /u/e/все эхи/-N:N
11. Делаем запрос(ы) /u/m для всех id из ответа пп10

Написал просто, чтобы не забыть.

Да, ещё, чтобы не забыть.

Допустим, мы используем endpoint /lim/100 и всегда фетчим последние 100 сообщений. Чем это плохо? Плохо тем, что если за это время накопится 200 сообщений, то у нас старые сообщения придут когда-то потом, после того как админ заметит проблему и сделает полный фетч.

Поэтому этот режим я никогда не рассматривал как надёжный. Он даже опасный.

Адаптивный фетч пытается решить эту проблему. В самой частой ситуации он сработает как /lim, но если окажется что сообщений всё-таки накапало больше, сдвинется назад.

lim это не для фетча, это чисто для клиентов. а переполнение при постоянном фетче живых эх вообще практически 0. такое может быть, если где-то rss бот сломался а потом вдруг выдал всё (и то в rss по 100 сообщений обычно не отдают). ну и я в lor.gold вкидываю сразу всю серию, там может быть и 200. а в клиентских эхах, по своему опыту, если я в фидо давно не забирал почту и в какой-то эхе куча сообщений, я максимум прочту несколько десятков последних и потом помечу эху, как прочитанную.

ps. у меня такое ощущение, что с такой экономией копеечного на самом деле трафика вы скоро на аутбаунд перейдёте. :) который я считаю главным недостатком фидо, я ровно сегодня думал, что фидо даже с сегодняшней моделью ii и тогдашними модемами на 300 байт/с, вполне могло бы жить.