Там ещё идея с подменой (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> открыл в 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

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

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

Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:

> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.

И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.

Я вот вместе с кодобазой tii начал вести свой ii-doc.txt, где описываю только реализованные в tii части протокола. И с пометкой IDEC extension у меня там только GET /x/features и один из вариантов /u/e, который со слайсами.

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

Слишком много сарказма. Если уж позиционируем протокол как альтернативу щитвебу и если уж спецификация не обязывает именно к HTTP(S)-транспорту (опять гитхаб процитировать?), то вполне логично принимать и предложения по более легковесным протоколам вместо упора в жирный HTTP(S).

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

Сделал у себя с шагом кратности 12 (потом 24, 48 и т.д.), чтобы в самом распространённом случае можно было даже с tgi и подобных за один запрос стянуть.

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

Ну в том алгоритме главная идея состоит в экономии трафика, полагаю. Сначала пробный запрос с -16:1, а потом, если в базе есть сообщение, то можно и -16:16.