На http://ii.blcat.ru/idec.talks правильный порядок - значит blcat берёт сообщения с меня чаще, чеми я с него, а revoltech по-видимому читает сразу всех и часто - я просто вижу его ответы раньше т.к. он мой поинт и отвечает через меня...

shaos>> а вот от msgid и далее делать неохота ибо оно криво будет работать т.к. порядок может быть чуть разный на разных нодах...
revoltech> Такого, кстати, быть не должно.

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

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

doesnm>> Отдачу сделать по CGI (читерство), а вместо nc взять /dev/tcp (фича баша)
revoltech> Да что ж везде одни теоретики... /dev/tcp только для клиентских соединений работает. Сервер сугубо на нём не сделаешь.

Перечитай на что отвечаешь. Серверная часть на CGI, клиентская на /dev/tcp. Как раз то, что ты пишешь, и выходит. Ну блин.

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

shaos> Возможно revoltech берёт сообщения Ромы прямо с blcat.ru и отвечает на них через меня

Я сейчас опрашиваю ноды в таком порядке: 1) https://sprinternet.io/iii, 2) https://hugeping.tk, 3) http://ii.blcat.ru, 4) http://idec.spline-online.ru. Соответственно, если его ответов на твоей и у пинга нет, то они выкачиваются и добавляются в локальную базу с ii.blcat.ru.

shaos> а revoltech по-видимому читает сразу всех и часто

Не так уж и часто. У меня фетч чисто в ручном режиме по кнопке на данный момент. Но порядок чтения уже написал.

Рома, не нервничай. У меня 3й день подряд мигрень, но я решил немного пояснить ситуацию, не влезая в детали. Как ты предложил. Но по существу! Мой ответ частично обращён к твоим другим сообщениям.

# Про дизайн и простоту ii

Я прекрасно понимаю твои доводы о простоте и сам практикую решения проблем "не в лоб". Это действительно круто, когда проблему можно "обойти" не решая её вообще. Plan9, кстати, отличный пример этого подхода. Я пришёл к этому не сразу, но когда так понял - сразу начал с радостью практиковать. На работе и в быту. И про питон + падения некорректных данных я тоже нормально отношусь. Мы пишем "чистые (сейчас не в терминах ФП)" функции при этом. А контролируемое падение питона (да ещё в рамках веб-фреймворка, например) это, обычно, не является проблемой безопасности.

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

# Проблемы "базового" ii

Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

- полный фетч;
- архивирование и "бегучесть" эх.

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

# Обсуждаемые изменения стандарта idec

Обсуждаемые изменения стандарта - в основном, реакция на взгляд со стороны о двусмысленных моментах. Андрей выкинул из текущего idec то, что посчитал лишним. Так что это упрощение. А то, что было неточно сформулировано - сформулировал. Речь вроде бы и не шла о "принципиально новом" стандарте. То-есть, мера хаоса была уменьшена, не революционно, но тем не менее. В этом и есть его ценность.

# Новый стандарт

Вот. А теперь самое интересное. Есть чистый стол. Есть ii. Есть упрощённый idec. И дальше развилка.

1) мне достаточно ii
2) мне достаточно idec
3) я могу сделать лучше

Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

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

Я лично могу сформулировать несколько вариантов:

1) ii с полным фетчем но с надёжным механизмом проверки изменений в эхах узла (это то, что у тебя hash эх
2) ii с возможностью забирать n последних сообщений (это твой lim и/или sf)
3) ii с отдачей списка msgid в обратном порядке (моя идея)

Каждая из них мне не нравится по своим причинам:

1) Необходимостью хранить счетчики/хеши/что угодно - мой шкурный интерес. Я тоже иногда люблю экстремальную простоту. Приемлемо, но не прекрасно.

2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

3) Вроде всё четко технически (читаем и обрываем связь когда считаем нужным) но.. Есть элемент хака.

Текущий idec в терминах простоты мне тоже НЕ НРАВИТСЯ, но! Я НЕ МОГУ придумать лучше и так, чтобы были решены те недостатки, о которых я говорю. И вот слайсы, достаточно просты и их таки решают! И этот адаптивный фетч который ты называешь оверинженирингом, для меня это вынужденный шаг. Другого пути я просто не вижу. Если хочу избавиться от полного фетча и при этом иметь надёжность которая позволила бы мне бросить ноду и не следить за ней год (хотя бы и гипотетически)

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

Подумал тут ещё... Хочу добавить. Может какой-то мозговой штурм начнётся. Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Адаптивный фетч тоже не 100% надёжен. Но ненадёжен по-другому. Речь о той точке алгоритма, когда мы останавливаемся. Когда видим что такое сообщение у нас есть и начинаем фетч. Это лучше чем жёсткий лимит, но всё-ещё не абсолютно надёжно.

Поэтому мне кажется, что в "идеальном" протоколе нужно выбрать что-то принципиально иное.

1) Либо полный sync если хоть что то поменялось (но тогда стоит вернуться и к перекатыванию эх, потому что в этом решении нет масштабировании при бесконечном росте эхи. Короче - это "принятие" ii)

2) Выборка, основанная на времени.

Вроде бы Рома делал такое когда-то, может ошибаюсь. Запрос вида: дай мне сообщения которые пришли с такого-то времени (время - ну пусть секунды эпохи unix в utc).

Да, тогда мы немного завязаны на время, но это вроде бы окончательно решает всё. Или нет?

Что думаете?

hugeping> Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Стоило прийти в idec, как его уже хоронят :)

tuple> Стоило прийти в idec, как его уже хоронят :)

Не надо вбросов! Давай по существу.

P.S. Ipv4 тоже хоронят давно, но что-то никак. :)

hugeping> Что думаете?

Продолжаю рассуждать. sf=hash становится надёжной, если только мы после последнего фетча запоминаем hash последнего сообщения которое зафетчили и сохранили. Возможно, о таком режиме Рома и говорил, но я до сих пор воспринимал sf=hash совсем по другому. Так что пишу это, если вы тоже воспринимали это по другому...

Так что sf=hash так же надёжна как и время, если мы после каждого фетча успешного записываем hash последнего взятого сообщения для этой ноды.

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

Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

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

shaos> Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...

shaos> Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).

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

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

shaos> А ну это сейчас вообще никем не фиксируется

Гм. Действительно, как-то я не подумал об этом. :)

Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

shaos> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

Да не, ерунда это всё. Не могу я, в общем, ничего принципиально иного придумать. Ну, а о реверсной выдачи ID что думаешь?

Реверсная выдача это когда клиент качает список в обратном порядке пока не дойдёт до знакомых хешей? Это может работать только для отдельных эх (типа /e но в обратном порядке).

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

echo.1:msgid999
echo.2:msgid998
echo.1:msgid997
…