>> Точно был способ в документации. Посмотрите подробней.
revoltech> Да уже всё перерыл, никак не нахожу, как именно клиентом выкачать все сообщения из указанных в /u/e за один HTTP-запрос.
revoltech> Так-то у меня и так выкачиваются только те сообщения, ID которых ещё нет в базе. Но проблемы с ограничением длины GET-строки на сервере это не решает.
revoltech> Самым очевидным решением было бы, наверное, разрешить ещё и HTTP POST /u/m с тем же синтаксисом.

У тебя трафик платный и тарифицируется по количеству HTTP-запросов?

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

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

Никуда не девается эта возможность. Скрытые эхи работают точно так же, как и те, что в list.txt.

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

Навернуть расширение для себя было бы лучше, чем ломать удобные фичи.

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

shaos> Ну это можно решить путём объединения эх в тематические группы (которые будут иметь смысл только на уровне узла и не будут задевать сам протокол) - например для временных или мелких эх может существовать тематическая группа unsorted…

Опять какие-то костыли :)

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

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

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

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

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

Божечки! Уже и карма. Куда катецо федо!

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

shaos> А может не будем про политику?…

Ну раз уж начали, то давайте. Чего уж там?

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

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

Я ничего никому не запрещаю и не разрешаю. Просто считаю отламывание фундаментальных фич вредительством.

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

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

Потому что только GET и есть.

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

shaos> Фуф, а я уж думал выяснится, что Лобанов - квадробер :)

Я сам думал уже кто же я. Квадробер, зацепер, видеоблоггер или, извиняюсь, рэпер. Но пронесло :)

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

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 сообщений, и в случае слайсинга ещё на серверной части до клиента они уже не дойдут никогда.

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

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

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

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

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

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

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

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

Тоже мне бином Ньютона, utf8 оттранслировать.

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

Например, пагинация индекса в условиях малого объёма оперативной памяти.

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

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

Это ты уже писал. Не писал только почему это вдруг проблема.

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

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

Новый поинт нажал кнопку "скачать" и скачал. Какие у него могут быть проблемы с первым выкачиванием эх? Или это у старлинка платное открытие нового соединения?

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

shaos> Чото тормозит она страшно последнее время - чем дальше, тем страшнее...

Да. Скоро будет переезд на новую кодовую базу. Если не случится ничего страшного, то буквально на выходных. Будет реактивная, с адаптивным фетчером и вот это вот всё.

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

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

да, естественно, просто url сдвигается. lim, в отличие от хэшей, я использовал реально в конфигах клиентов. хотя щас у меня две ветки, 0.6 на фандейшне (активная) и 0.7 на пикнике (недоделанная), и я не перенёс эту фичу с 0.7 в 0.6, надо будет не забыть

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

те или иные варианты discover, типа автодобавления, вроде были всегда, у меня вроде и серверы и клиенты с такой фичей были.

но тогда, если останется автосоздание эх другими, в интерфейсе будет бардак. можно просто принять какой-нибудь протокол типа /x/discover, который будет делать элементарное os.listdir('e'), у меня сейчас так gemini-сайт работает.

с другой стороны это надо только для архиваторов, ибо у нас у каждой станции свой набор эх, и это замечательно. :)

Андрей, а что с rss-гейтом? Мёртв с 16 числа.

ahamai> shaos, проверь repto? если кривые, то вычищаем тему

Вполне возможно что у тех десятка сообщений что я заблеклистил было все ок с repto (его не было), но это тупо создаёт десяток однострочных топиков в духе -- а, вот - заработало.

Чистить уже ничего не надо, я заблеклистил это. А на будущее видимо мне все таки придётся писать фильтр на fetch.

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

ahamai> форвардинг в более подходящую эху - это нормальная фидошная практка.

Я понимаю, тут просто конфликт "философий". Это неизбежно. Ты создаёшь "движуху" ради движухи. Это нормально, но мне эти сообщения о том что там как-то что то работает или не работает, и все эти "меня видо" - не нужны. Они не посвящены никакой теме. В фидо я ценил "тематичность", а не все эти флейм-конференции... Но если в фидо были модераторы, то тут... нет. Если бы я был модератором я бы сказал что есть pipe - пишите туда. Там флейм. А сам бы отписался бы :)

idec.talks вроде бы относится к всему что idec, но это же не тестовые сообщения? Увели беседу в idec.talk - спасибо shaos! А теперь снова вернули и все в помойку... Короче, ладно. Понятно что такие "конфликты" будут всегда. Я сам подумаю над политикой на своей ноде и не буду лезть дальше.

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

Наверное, мы о разных вещах говорим.

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

Вопрос знатокам: увидит ли клиент те несчастные три сообщения?

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

У меня идеология не тратить вычислительные ресурсы там, где их можно не тратить. Пермакомпьютинг так называемый.

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

Я тебе советовал посмотреть как написан фетчер в ii-go. У тебя есть своё понимание, но оно не соответствует тому, как работает адаптивный фетч. Сил объяснять у меня нет. Скажу только, что забор индексов идёт "бинарно" (по одному id) начиная с 1 (2, 4, 8, 16, ...) пока не обнаружим те сообщения, которых у нас нет и тогда мы их все забираем. Ну или если мы дошли до какого-то лимита-ограничения, тогда переходим к старой схеме - забрать все.

hugeping>> Слушай, ну зачем этот хаос. Я вот осознанно не фетчу idec.test. Без предупреждения.
hugeping>> Снимаю пока фетч и занимаюсь зачисткой.
hugeping> Фух. Зачистил. Оставил только один топик Re: Мея видно? так как он хотя бы с нормальными repto: выстраивается в одну тему.
hugeping> Вообще, я начал думать что нужны фильтры того, что от кого брать...

Все хотят огородиться от хаоса :)

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

ahamai> shaos, почему с тебя idec.test не фетчится?
ahamai> ps. Ценность маленьких запросов понимаешь, когда фетчишь с spline :)

Я просто тормоз. Всё ок :)

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

> Они не посвящены никакой теме.

что значит никакой. это тема про tii/tiix, я её и вывел для сохранения в историю. а то потом эти мессенджеры обгонят телеграм, а у нас опять архивы потеряны.

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

> Я на gopher://hoi.st обитаю, если что.

открыл в lynx, попытался перейти в веб, пишет "ошибка документа"

других gopher клиентов я не помню, бомбадила вроде умеет, но он вроде веб не умеет

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

В общем, я понял, какой алгоритм до меня пытаются донести:

1. Делаем GET /x/features, чтобы проверить на предмет x/c и u/e. Если они имеются, то выполняем следующие пункты, если нет, скачиваем все айдишники через GET /u/e/имя.эхи и слайсим только на клиенте.
2. Делаем GET /x/c/имя.эхи, чтобы сравнить количество сообщений с локальным. Пишем разницу между полученным и локальным в diff.
3. Потом делаем GET /u/e/имя.эхи/-diff:diff и получаем список новых айдишников.

Так, что ли?

Капец там запросов, оверхед.

x/features вообще должна кешироваться, сервер не меняет серверное по каждый день, чтобы это постоянно запрашивать

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

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

Алгоритм ii-go:

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

Возможны гонки, например когда сообщение успеет добавиться (в конец) пока мы забираем текущее. Но на следующем fetch мы должны будем это заметить.

Зачем столько запросов? Это и лишняя нагрузка на сервер, и лишний трафик (хедеры, все дела). Почему не делать шаги типа 1, 16, ещё чёнить, всё, то есть более частые юзкейсы. или даже сразу начинать с 16. запрос вообще вещь дорогая, и их лучше минимизировать

hugeping> 2) n = 1

Да, только вот этот шаг настраивается. То-есть там не 1 в реальности, а параметр limit. У меня это что то-вроде 15.

AL> Все хотят огородиться от хаоса :)

Я вообще сейчас подумал, наверное для меня лучшим решением было бы иметь две ноды.

1-я -- просто обычная idec нода без наворотов итд. без web морды.
2-я -- ii-go для блога, инстеда итд. с веб мордой

И синкать 2ю с 1й только по тематическим эхам. :) Вообще, надо откатываться к корням... сделать что ли чисто ii ноду... :) Нет, второй раз это не прокатит!

P.S. Когда цезий возродишь? :)

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

А зачем так сложно? Если нода умеет слайсы, то она, по идее, умеет и /x/c, который неубываемый. Тогда мы, сравнивая с количеством уже скачанных локально сообщений, знаем, сколько надо ещё запросить.

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
hugeping>

А почему бы просто не сравнить результат /x/c с тем количеством, что уже локально скачано?

revoltech> А почему бы просто не сравнить результат /x/c с тем количеством, что уже локально скачано?

Потому что в разных нодах могут быть особенности. Например блеклист - учитывается или нет в счётчиках? Нода может не хранить все сообщения, а только часть (последние 10000). Причём это может быть особенность как собственной ноды, так и той ноды с которой мы фетчим. Ну и другие ситуации, которые можно придумать. А хеши - надёжно.

Проверил каждое сообщение - там где есть repto оно ведет куда надо - на новую копию сообщения

Есть только одно сообщение с перепутанными полями (где сабж shaos) - его наверное можно заблеклистить

Как и одно с абракадаброй вместо текста…

hugeping> Ну и другие ситуации, которые можно придумать. А хеши - надёжно.

Чуть лучше, хранить счётчик на диске для конкретной станции - свой счётчик. Но тоже ненадёжно.

Номер может остаться тот же когда скажем добавили 1 сообщение, но в то же время заблеклистили 1 из середины - поэтому идея с хешами списков хешей мне кажется более работоспособной

Количество в общем случае не показатель - сообщения могут не только добавляться, но и удаляться

shaos> Количество в общем случае не показатель - сообщения могут не только добавляться, но и удаляться

На этот счёт спецификация явно говорит, что счётчик может только увеличиваться. Лучше стянуть один-два уже существующих локально айдишника, чем потерять какие-либо.

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

> На этот счёт спецификация явно говорит, что счётчик может только увеличиваться.

Но на практике у всех разные номера для тех же самых эх...

Заблеклистил несколько сообщений, которые 100% тестовые либо кривые

hugeping> Потому что в разных нодах могут быть особенности. Например блеклист - учитывается или нет в счётчиках? Нода может не хранить все сообщения, а только часть (последние 10000).

Если верить документации с гитхаба idec-net, то всё это не должно уменьшать счётчик. Сообщение добавилось — инкрементировали. Сообщение удалилось — счётчик не трогаем.

> Но вред файлэх в чём?

1. Там передаётся нетекстовая информация т.е. через терминал уже не будет работать
2. Функционально файл из файлэхи это просто забирание файла по HTTP - зачем городить лишние абстракции?
3. Сейчас (на таверне) оно используется в основном только для раздачи порнухи и пиратских книг...

Сообщение можно не только заблеклистить, но и удалить

shaos> Сообщение можно не только заблеклистить, но и удалить

Да пожалуйста, но счётчик при этом трогаться не должен.

Из https://github.com/idec-net/new-docs/blob/master/extensions.md:

> Важно: параметр неубывающий. Если в эхе удалили сообщения, то возвращаемое число не должно уменьшаться.

в ii-php уменьшается

технически это немножко сложно его неуменьшать

это если хранить по простому в файлах

а если в SQL то там можно просто max(index) выдавать и он всегда будет расти (но фактически сообщений будет меньше)

shaos> в ii-php уменьшается

Ну, это печально. Получается, спецификации оно не соблюдает. Соответственно, в клиентах вся завязанная на счётчики логика тоже идёт лесом.

Придётся и у себя откатить. Или перепилить на нечто подобное алгоритму из ii-go, посчитав накладные расходы.

shaos>> в ii-php уменьшается

revoltech> Ну, это печально. Получается, спецификации оно не соблюдает. Соответственно, в клиентах вся завязанная на счётчики логика тоже идёт лесом.

У меня тоже, наверное, не соблюдается в полной мере. И когда делал свою реализацию понял, что затачиваться на счётчики - потенциальная стрельба в ногу. К сожалению. На мой взгляд пример непродуманного элемента стандарта. Например, упал винт и ставишь всё заново. Откуда брать счётчик? Если у нас все базы данных зеркальные копии - то, вероятно, можно взять его у "соседа". Но рассинхронизация этих счётчиков между узлами с одинаковой эхой может произойти очень легко. К тому же, та другая нода скорее всего хранит последнее состояние моего счётчик у себя для проверки изменений при фетче. Короче, малейшие отличия в реализации и всё... А счётчик оказывается и не счётчиком сообщений и не счётчиком изменений...

Но! Главная мысль в другом. Даже если бы эта штука работала у всех одинаково и хорошо, она не решает ничего. Она просто позволяет сказать - стоит ли делать фетч или нет. Эту же вещь дают и слайсы, но надёжным способом. Важнее другая фича. А именно - да, нужно фетчить но фетчить не всё. Потому что в обычной ситуации в эхе всегда будут новые сообщения. Эту проблему тоже решают слайсы но только в режиме адаптивного фетча. Мне кажется адаптивный фетч - это вообще мое изобретение к которому я пришёл вынужденно. Все другие способы имели свои проблемы и нюансы. Но вот это "двоичное" сканирование истории - даёт хороший результат. Но.... сложно!

Конечно, сейчас хочется сказать - а давайте вернёмся и придумаем что-то более простое и надёжное и сделаем что-то среднее между ii и idec... Но боюсь, лишние потрясения нам не к чему.

Там ещё идея с подменой (amend) сообщений выглядит интересной - идеологически верная альиернатива редактированию старых мессаг...

хотя не - max(index) не будет работать т.к. индекс общий на все эхи
видимо надо запрещать удалять сообщения физически...

shaos> хотя не - max(index) не будет работать т.к. индекс общий на все эхи
shaos> видимо надо запрещать удалять сообщения физически...

Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы. Тогда ничего не надо городить и счётчик - полное число сообщений эхи, включая блеклист. Вот меня тоже давно грызёт мысль что нужно что-то упрощать. Но я боюсь что то менять. :)

shaos>> хотя не - max(index) не будет работать т.к. индекс общий на все эхи
shaos>> видимо надо запрещать удалять сообщения физически...
hugeping> Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы. Тогда ничего не надо городить и счётчик - полное число сообщений эхи, включая блеклист. Вот меня тоже давно грызёт мысль что нужно что-то упрощать. Но я боюсь что то менять. :)

Работает - не трогай?

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

> Конечно, сейчас хочется сказать - а давайте вернёмся и придумаем что-то более простое и надёжное и сделаем что-то среднее между ii и idec... Но боюсь, лишние потрясения нам не к чему.

если shaos введёт ?h=1, то я при его запросах буду действовать по следующей стратегии, сначала смотреть хэши эх, потом дёргать изменившиеся, полностью, крохоборить и выбирать кусочки списков я не буду. думаю, это сократит трафик. потребует минимальных изменений фетчера. и сама фича в моей ноде есть сто лет в обед, только никогда не использовалась.

> Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы.

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

doesnm> Работает - не трогай?

Тут скорее боязнь конфликтов и войны "стандартов". Всё-таки, стандартны - вторичны. Первичны - люди. Так то, по мне, нужен откат к идеям ii но с опытом полученным в idec.

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

Ну и не всё так однозначно. Например, нужны слайсы или нет, если проблема фетча будет решена без них? Я бы сказал - не нужны! Но ведь действительно, бездисковый клиент мог бы пользоваться слайсами для "браузинга" сообщений! Так что рубить с плеча не стоит.
P.S. Edited: 2024-10-25 16:18:07

> Там ещё идея с подменой (amend) сообщений выглядит интересной - идеологически верная альиернатива редактированию старых мессаг...

изнаачально задумывался механизм revoke, но это бы сильно всё усложнило, проще заблеклистить и выпустить ещё раз. я не знаю, щас блеклистами не меняются вроде, а раньше менялись. заблеклистил и сделал новое, дополнительные сущности тут не нужны

у меня фетчер, оказывается, вообще без поддержки blacklist :)

Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

2) Вариант с хешом эхи как индикатором изменений - не решает проблему забирать не всё, а только часть. Да и предполагает хранить на диске или в базе последний хеш;

3) Вариант "дай мне всё, что пришло после такого-то времени", возможно, самый интересный. Но уже накладывает ограничения: синхронное время, необходимость делать выборку по времени итд

4) Вариант возвращать список id в обратном порядке. Идея в том что если я получаю список в обратном порядке я могу закрыть соединение в тот момент когда мне уже больше не надо. :) Но, как-то на хак похоже. А как вам? Не знаю... Нет красоты.

Получается, ничего проще слайсов и не сделать? :)

hugeping> Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

hugeping> 1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

Хотя, сработает. Если брать с разумным "запасом" на самом деле... Правда опять вопросы с блеклистами и удалениями могут быть.

shaos>> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)
revoltech> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

Это было в ii.

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

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

Зачем брать сто, а не то, чего у тебя нет?

AL>> У тебя соединения платные или что?
revoltech> У меня идеология не тратить вычислительные ресурсы там, где их можно не тратить. Пермакомпьютинг так называемый.

Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

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

>> Но вред файлэх в чём?
shaos> 1. Там передаётся нетекстовая информация т.е. через терминал уже не будет работать

Постоянно работаю с файлами в терминале.

shaos> 2. Функционально файл из файлэхи это просто забирание файла по HTTP - зачем городить лишние абстракции?

Транспорт может быть любым.

shaos> 3. Сейчас (на таверне) оно используется в основном только для раздачи порнухи и пиратских книг...

Не подписывайся. Вопрос был концептуальный, а не по конкретным фехам.

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

Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.

Вредоносные вещи, типа эх только для чтения, кармы и прочих извращений щитвеба не пущать.

Продумать систему наказаний поинтов (накопление плюсиков, перевод в "только чтения", отключение от эхи) на уровне стандарта.

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

hugeping> P.S. Когда цезий возродишь? :)

Цезий ждёт похорон. Допилю ноду, продолжу пилить цезий+ :)

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

предлагаю включить в стандарт возможность исполнения list.txt?h=1

AL> Это было в ii.

А почему документация описывает это как IDEC-расширение?

AL> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.

а количество плюсиков не равно обратной карме? ;)

> Это было в ii.

А почему тогда list.txt и blacklist.txt перечисляется в /x/features?

curl -XGET http://idec.spline-online.ru/x/features
u/e
list.txt
blacklist.txt
x/file
x/small-echolist
x/caesium
x/c

О - кстати, а что такое x/small-echolist?

u/e тут тоже есть :)

собрал все сообщения всех станций. пока всё криво и косо :)

http://ii.blcat.ru:5000

кроме spline, до неё так и не достучался

AL> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики

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

1) получили счётчики
2) нарисовали пагинатор
3) по мере "листания" пользователя - проходим сообщения слайсами

Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.

P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....

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

for n in `wget -q -O - http://ii.blcat.ru/e/idec.talks | tac`
do
wget -q -O - http://ii.blcat.ru/m/$n | less
done

переключаться клавишей q :)

ahamai> Зачем столько запросов? Это и лишняя нагрузка на сервер, и лишний трафик (хедеры, все дела).

Напиши конкретный алгоритм, я не понял твоё предложение.
Начинаю я с -16:1 - я там выше написал что лимит это параметр. В описании алгоритма я для понятности задал его в 1, но в быту мы начинаем не с 1. И обычно, если сообщений < 16 новых это единственный запрос. Если нет, будет -32:1, потом -64:1....

ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1

А что это значит, напомни?

ahamai> кстати, а зачем ты меня вообще фетчишь? :) мой аплинк shaos, мы меняемся с ним трафиком, и уже от него по идее он должен попадать в остальную сеть. типа чтобы сообщения быстрее доходили?

Я и не фетчу (пока). Я тебе писал как к автору инициативы форвардить из теста в talks. :)

ahamai> открыл в lynx, попытался перейти в веб, пишет "ошибка документа"

А я хотел заценить твой гемини и... лежит... :(

а кто тогда фетчит idec.talks с меня? :)

http://ii.blcat.ru/list.txt?h=1

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

я даже не помнил, как сервер называется :) gmid оказывается, нашёл, включил

ну 16 норм, но потом бы я шаги увеличивал, там 64, потом 256 потом все сообщения. или вообще 16 если чё-то не хватает то забирать все. думаю, такие триггеры будут редко срабатывать.

стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.

Мне нравится идея, что у каждого свой суверенный блеклист :)

Лучше когда все фетчат всех - и надежнее, и быстрее сообщения доходят :)

> Мне нравится идея, что у каждого свой суверенный блеклист :)

ну сейчас - да, и в принципе это норм

Даже пример реализации пролетал :)

https://github.com/gk11-ru/ii-elp/blob/master/run.py#L24

Сегодня-завтра попробую у себя добавить

Плюс listhsh.txt как алиас того же самого плюс /x/h который как /x/c но вместо номеров - хеши хешей

shaos> Даже пример реализации пролетал :)

Мне идея хешей эх не нравится. Придётся хранить состояние последнее на диске при фетче. Теряется эстетика простоты. Кроме того, сплайсы и так решают эту проблему (но более элегантно). В общем я понял, стандарт лучше не трогать!

ahamai> я даже не помнил, как сервер называется :) gmid оказывается, нашёл, включил

Ну то есть это будет заброшено при первом же ребуте сервера? Ок, тогда не буду пока добавлять в ссылки на своей капсуле.

не, я сделал rcctl enable gmid, ща будет автостартовать :)

> Мне идея хешей эх не нравится.

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

> Придётся хранить состояние последнее на диске при фетче.

хранить предыдущий list.txt, только и всего. зато меньше лишних запросов, большинство эх перманентно мёртвые. я жду, когда shaos сделает ?h=1, чтобы под это фетчеры адаптировать и не гонять лишнее.

AL>> Это было в ii.
revoltech> А почему документация описывает это как IDEC-расширение?

Потому что документация описывает IDEC.

AL>> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?
revoltech> К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.

Слишком много оверхеда.

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

shaos> а количество плюсиков не равно обратной карме? ;)

Нет :)

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

ahamai> Андрей, а что с rss-гейтом? Мёртв с 16 числа.

Умер.

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

ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1

Что это должно делать?

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

AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики
hugeping> Я тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть:
hugeping> 1) получили счётчики
hugeping> 2) нарисовали пагинатор
hugeping> 3) по мере "листания" пользователя - проходим сообщения слайсами
hugeping> Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.

Мысль интересная, но я бы за такие манипуляции со своей станцией карал :)

hugeping> P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....

Там они показывают фактическое количество сообщений. То есть могут иметь отрицательный рост :)

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

>ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1

>Что это должно делать?

Возвращать хеши эх вместо дескрипшина:

idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz

что с лор.опеннетом делать будем?