hugeping> У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

hugeping> Каких метаданных и почему куча соединений?

revoltech> P.S. Да, ещё раз пардон, перепроверил — то у tgi только 12 сообщений за раз можно выгрести. У остальных 389, у тебя вообще лимит 10000 вроде хавает без проблем. Правда, spline-online не тестил, он и так еле живой сейчас.

ahamai> Ну и есть всякие плюшки типа минимальной гарантии доставки

ahamai> Для меня простота - это возможность в несколько строк написать фетчер хоть на python, хоть на busybox, поэтому я буду поддерживать реализацию только через http. Но всегда интересно посмотреть на сторонние проекты.

ahamai> увеличил буферы в nginx. скормил url на 89 кбайт - сожрало

>> Для того, чтобы её не было, нужно писать дополнительный код, который по идее вообще вредный, так как удобную фишку убирает….
shaos> Ну например можно выкинуть «вообще вредный» код файлэх, который сейчас чуть ли не половину всего кода ii-php занимает :)

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

shaos> Надо будет фичу выпилить ;)
shaos> Объясню - по мне так должна быть возможность программно вытянуть весь контент узла любому кто не есть админ узла (причём через веб можно возможности и поурезать т.к. вебом не только люди пользуются), а со скрытыми эхами такой возможности нет.

shaos> Ну и чисто административный момент - даже если сисоп временно потерял физический доступ к узлу (уехал в отпуск) у него должна оставаться возможность видеть что там происходит пользуясь открытыми апи (напрямую либо через ботов)…

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

shaos>> Объясню - по мне так должна быть возможность программно вытянуть весь контент узла любому кто не есть админ узла (причём через веб можно возможности и поурезать т.к. вебом не только люди пользуются), а со скрытыми эхами такой возможности нет.
revoltech> Так, может, лучше тогда автоматизировать их добавление в list.txt, то есть сделать их НЕ скрытыми, вместо урезания полезной фичи?

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

shaos> При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,

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

shaos> Ну это издевательство над здравым смыслом когда одной рукой вы разрешаете декларировать поддерживаемые фичи через features, а другой запрещаете эти фичи расширять…

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

shaos>> Это да :)
revoltech> Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов по 12 айдишников из-за ограничений хттпшного гета на сервере, а чем-то более вменяемым? Или нет? В доках ничего, кроме GET /u/m, по этому поводу не нарыл.

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

iiii> Я не понимаю, как это работает, я не знаю как запросить последние n сообщений и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине. Количество сообщений я считаю ненадёжным источником, можно удалить 1 и жобавить 1 и эха вроде не изменится. , в отличие от хэша. Я вообще при делании срезов не понимаю, что входит а что не входит. Поэтому у меня на станции нет постраничного вывода :)

/u/e/idec.talks/-100:100

заберёт последние 100 сообщений.

iiii> А lim совместим со всем, хоть с ii txt 0.1, меняется только строка в конфиге.

При этом будет работать и /lim/200/u/m и /lim/200/u/point?

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

hugeping>> А слайсы решают проблему больших индексов.
revoltech> Слайсы на сервере позволяют пропустить сообщения, только если действительно не гонять их каждые пять минут. А это действительно увеличит трафик и без того.

revoltech> Мой юзкейс — зашёл утром, запустил tiifetch.tcl или нажал на кнопочку Fetch all echos в tiix, клиент докачает изменения всех эх за ночь и в течение дня дофетчиваю только новое содержимое конкретно интересующих эх, вручную жмякая на Fetch this echo при необходимости. За это время в них может собраться куда больше 100 сообщений, и в случае слайсинга ещё на серверной части до клиента они уже не дойдут никогда.

revoltech> Поэтому придерживаться базового протокола мне пока кажется более разумным, только вот с выгребанием по /u/m надо что-то решать. 12 айдишников на запрос — слишком мало, а многопоточность всё равно не решает проблему с кучей TCP-соединений и HTTP-метаданных.

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

shaos> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение:

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

>> если IDEC уже имеет все средства как часть стандарта, то зачем для него городить кастомные гейты?..
ahamai> Без гейта ты нормально не отобразишь ничего ни на zx spectrum ни на msdos, ни на atari st. Сначала научи их utf8 :)

ahamai> Хочется хоть одно реальное применение слайсов, кроме "забрать последние сообщения"

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

shaos>> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение
revoltech> И там AL написал, что POST /u/m не решает ни одной проблемы. Как же не решает, если решает? Вот вам проблема: куча лишних соединений и метаданных, т.к. владельцы станций ограничивают длину GET-запросов, либо сознательно, либо оставляя дефолт на веб-сервере. С POST запрос будет всегда одним в идеале.

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

ahamai>> Сегментирование запросов было введено специально.
revoltech> Чтобы создать новым поинтам затруднения с первым выкачиванием эх (а-ля блокчейн монеро)?

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

> При этом будет работать и /lim/200/u/m и /lim/200/u/point?

> Вот. Товарищ дело говорит!

AL> Удивительно. 9 лет у всех всё доходит, а у тебя нет. Может, надо что-то в фетчере поменять?

AL> У тебя соединения платные или что?

revoltech> 1. Фетчер по server-side слайсу качает 100 последних сообщений вечером.
revoltech> 2. За ночь в эхе появляется 103 сообщения.
revoltech> 3. Фетчер по server-side слайсу качает 100 последних сообщений утром.
revoltech> Вопрос знатокам: увидит ли клиент те несчастные три сообщения?

AL> Только если узел, внезапно, пишет в середину индекса, а не только в конец.

AL>> Только если узел, внезапно, пишет в середину индекса, а не только в конец.
revoltech> В общем, я понял, какой алгоритм до меня пытаются донести:

hugeping> 2) n = 1

hugeping> Алгоритм ii-go:
hugeping>
hugeping> 1) если есть поддержка слайсов то используем её. иначе - полный синк
hugeping> 2) n = 1
hugeping> 3) берем /u/e/эха/-n:1
hugeping> 4) это сообщение есть в базе? да - не нужен синк (goto 7)
hugeping> 5) n = n * 2
hugeping> 6) идём на 3
hugeping> 7) забираем сообщения от -n:n