Так. Я могу задать срез последней, я могу задать каждой. А если я задам не каждой, а некоторым, что будет тогда?

По идее можно попробовать и /lim/N/u/e/ поддержать, но через хак - оно будет смотреть если это /lim/N/u/e/ то само будет переупорядочивать в /u/e/lim/N/

ahamai> мемо забыл проставить. ну хоть так, метамемо поставлю

Что такое memo

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

http://ii.blcat.ru/memo00

Очень желательно сделать на станции отличие одной страницы от другой в title вкладки. А то в истории браузера сохраняется просто как:
- ping
- ping
- ping
- ...

А хотелось бы что-то вроде:
- [ping] echo/all // общая лента
- [ping] Re: разборки с IDEC // для тредов
- [ping] Жертвы разборок
- [ping] Новый протокол - VINI: VINI is not IDEC

Сделал

> curl -XGET https://sprinternet.io/iii/lim/3/u/e/retro.talks/english.talks
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

Сделал хак для поддержки /lim/N/u/e/...

> curl -XGET https://sprinternet.io/iii/lim/3/u/e/retro.talks/english.talks
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

работает также как и

> curl -XGET https://sprinternet.io/iii/u/e/lim/3/retro.talks/english.talks
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

ahamai> Да и пойнт тебе с u/e ничё не сделает.

Без фильтрации айдишников — ой как сделает.

> Так. Я могу задать срез последней, я могу задать каждой. А если я задам не каждой, а некоторым, что будет тогда?

Когда ты задаёшь "срез" в конце, то он распространяется на весь список

Если надо чтобы что-то из списка брало по своему, то там надо указать свой "срез" либо волшебное слово all либо волшебное слово last

типа /u/e/echo.1/echo.2/all/echo.3/last вернёт всё для echo.1 и echo.2, но только хеш последнего сообщения для echo.3

ну ещё lim можно воткнуть в середину - вот такая запись сделает тоже самое:

/u/e/echo.1/echo.2/lim/1/echo.3

короче полная гибкость и свобода выбора :)

ну конечно оно в каком-то смысле дублирует слайсы :)

короче с хаком теперь работает, но только применительно к /u/e т.е. например /lim/3/list.txt у меня не пройдёт ;)

Хак:

elseif (($opts[0] == 'u' and $opts[1] == 'e') ||
        ($opts[0] == 'lim' and $opts[2] == 'u' and $opts[3] == 'e')) {
	$work_options=array_slice($opts, 2);
	// lim/N/u/e hack
	if($opts[0] == 'lim') {
		$work_options[0] = 'lim';
		$work_options[1] = $opts[1];
	}

Жесть. Ты теперь обязан жениться на u/e

По ходу пьесы удалил около 500 строк отвечающих за файлэхи - это было порядка 20% всего кода ii-php (сейчас осталось чуть больше 2000 строк), а чтобы поддержать в /u/e/ слайсы где попало, lim/N, выдача по хешу, выдача по времени сохранения плюс хак /lim/N/e/u потребовалось добавить меньше 50 строк...

> сейчас осталось чуть больше 2000 строк

там ведь ещё есть неиспользуемый сейчас транспорт MySQL - я пока думаю стоит туда вообще залезать или остаться в рамках файлового представления

наверное надо пересаживаться на MySQL хотя бы для хранения метаданных типа цепочек тредов, таблиц поиска и т.д.

tuple> Очень желательно сделать на станции отличие одной страницы от другой в title вкладки. А то в истории браузера сохраняется просто как:

Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

hugeping> Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

Да, классно теперь. Только https://club.hugeping.ru/echo/all/ отображается как "club.hugeping.ru/echo/all".

hugeping>> Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

tuple> Да, классно теперь. Только https://club.hugeping.ru/echo/all/ отображается как "club.hugeping.ru/echo/all".

Ага, ещё несколько случаев добавил. Если что, пиши. Для меня web ii-go сейчас близок к идеалу. Но иногда что-то меняю по мелочи.

Зашёл на станцию hugeping а там уже будущее :)

Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)

Не могу понять, но от тебя периодически перестаёт ходить эха linux.14. Вот только эта эха. Проблему понять не могу

shaos> Если надо чтобы что-то из списка брало по своему, то там надо указать свой "срез" либо волшебное слово all либо волшебное слово last

Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.

https://hugeping.tk/u/e/idec.talks/0:0 - всё
https://hugeping.tk/u/e/idec.talks/-1:0 - последнее (ну или -1:1)

shaos> Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...

Если в каждой эхе у нас новых сообщений от 128 до 256 штук, то для 1000 запросов, с учётом того, что запрашиваем по одной эхе, нужно запросить 125 эх. Это раз

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

Бандлы по 40 сообщений... Если мы возьмём те самые 125 эх, в которых у нас по 256 новых сообщений и начнём их выкачивать такими вот бандлами, у нас всё равно будет 800 запросов, что меньше заявленного тобой ужасного числа на 20%.

В реальности такой оверхед будет только для новых узлов и разово. Дальше, при фетчинге хотя бы пару раз в день, количество запросов будет от силы несколько десятков на сессию, что меньше 10% от заявленного.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

1. я снял срезы. они почему-то вообще трафик не экономят, как был 2-4 мб так и остался, хотя x/h сильно его экономит. не понимаю, я же тяжёлые лор-опеннет и хабр.рсс тащу.

2. я создал эху spnet.uplink и поставил её фетч на тебя. поставь её фетч на меня, будем там решать проблемы нашей связи :), проблем, эх для гейтования и прочего, думаю здесь этому не место.

> Без фильтрации айдишников — ой как сделает.

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

1. у нас есть файл с такой эхой - отдаём этот файл
2. у нас нет файла с этой эхой, отдаём пустую эху

третьего не дано

> А потому что нефиг завязываться на точку было. Сделали бы 1) что-то в духе /u/l (в моём новом несовместимом протоколе будет /r/l вместо list.txt), 2) в выводе /u/e после каждой эхи (для отличия от msgid) ставить двоеточие. И всё, никаких коллизий.

так это теперь фича. пишешь туда то, что не хочешь, чтобы высвечивалось в веб :) раньше была внутренняя сисопская эха, которую мы называли "дальний кордон", типа "смотри я тебе на дальний кордон отправил". а теперь будет тайная эха, или эха-которую-нельзя-называть, и можно так же что-то туда написать и туда же послать :)

Я после всех этих обсуждений засомневался, а может быть и правда нам нужны множественные слайсы в 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

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

Алгоритмы хорошо, но есть ли реальные замеры. Тестируй разные варианты на shaos, он подробную статистику ведёт :)

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

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

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

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

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

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

> Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.

0:0 у меня таки сработает как all
а вот -1:0 надо посмотреть...

> Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)

Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...

2. сделал spnet.uplink

> Жесть. Ты теперь обязан жениться на u/e

Выходит что так :)

Всё равно наверное надо скажем раз в неделю делать полное забирание всего - чисто на всякий пожарный...

-1:0 не работает (точнее работает, но возвращает 0 хешей)
но я эту логику не трогал - видимо ii-php всегда так работал
исправлю

Проверил старый ii-point.php - он и по 0:0 возвращал 0 хешей :)
Так что я получается это уже частично исправил ;)
Осталось N:0 исправить...

shaos> Осталось N:0 исправить...

Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
Но никто не использовал их в таком режиме. Исправил.

> Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
> Но никто не использовал их в таком режиме. Исправил.

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

> Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...

мне не нравится, когда все фетчат всех :) мне привычнее схема аплинков-даунлинков. а 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.

> Осталось N:0 исправить...

Исправил - заменяю количество 0 на 999999999 (один миллиард минус 1) т.к. вряд ли когда-нибудь в ii/IDEC будут эхи с количеством сообщений больше миллиарда - ограничение такое сделал ещё и из-за того, что у меня в /u/e/ теперь unixtime может пролетать и для простоты он у меня определяется как число >=1000000000 что соответствует Sun Sep 09 2001 01:46:40 GMT+0000 (не думаю, что в ii/IDEC когда-либо попадутся сообщения древнее сентября 2001 года)...

Заметил лишний пробел:

> Количество сообщений указывается от 0 до произвольного числа. Если количество равно нулю, индекс строится от смещения до конца. Если сумма смещения и количества превышает фактическу ю длину индекса на узле, отдаются все msgid от смещения до конца индекса.

фактическу_ю

Теоретически кто может сконвертить фидошные, с оригинальной датой. Лучше убрать один порядок :)

> Узел должен обеспечивать запрос 40 сообщений в одном запросе /u/m. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.

Может быть первое предложение подкорректировать?

Количество одновременно запрашиваемых сообщений в одном запросе /u/m не должно превышать 40. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.

Это не дата в заголовке сообщения, это дата когда сервер это сообщение принял либо по фетчу, либо по пушу, либо через поинтовый апи, либо путём копирования файлов извне (у меня сейчас - дата модификации файла сообщения). Ясно понятно, что 2001 год там быть не может. Да и в заголовке старая дата как бы не должна быть т.к. это timestamp проставляемый сервером при конвертировании ii сообщения из поинтового в сохранённое, чего никак не могло произойти раньше 2014 года...

И потом этот unixtime используется для отрезания сообщений в /u/e - типа дай мне всё что новее, а это обычно прям щас, не в прошлом

Тут ещё такой момент есть - ii-php со стародавних времён накладывает блеклистовый фильтр уже после того, как слайсы посчитаны и выходной список софрмирован, т.е. например если последнее сообщение в эхе заблеклисчено, то -1:1 вернёт ничего. По идее это решается административно путём принятия за правило никогда не блеклистить последнее сообщение в эхе - пусть оно немного "полежит" :)

А так надо быть готовым к тому, что запросив у меня скажем -10:10 можно получить в ответ только 9 сообщений...

а где попасть на сабж? ссылки на http в gopher у меня на том сайте не открываются :(

Да, хэши рулят. А вот срезы, на моё удивление, вообще трафика не снизили, до хэша было 12, с хэшем 2, поставил срезы, стало 4.5, потом 2.7, потом 2.5. убрал срезы, буду смотреть твою статистику за вчера и сегодня.

вообще изначально большие блеклисты не имели смысла - сисопы блеклистили, потом вычищали у себя из баз, а потом и снова удаляли из блеклистов. щас я так понимаю каждый свой блеклист ведёт :) раньше он был фактически общий