ahamai>> Потому что вы не делали Дизайна проекта, принимая много решений "как поступить", а базируетесь на уже готовой реализации, когда те решения, которые есть, кажутся уже сами собой разумеющимися.
revoltech> С моей колокольни стороннего наблюдателя и имплементатора мне важны чётко документированные элементы протокола и как бы всё. С точки же зрения дизайна здесь, как говорится, есть два стула: либо ломаем вообще всю обратную совместимость и радикально упрощаем протокол (а упрощать и правда есть куда даже после выпиливания кучи эндпоинтов из стандарта), либо же проще оставить как есть, т.к. любые оптимизации ПРИ сохранении обратной совместимости приведут только к усложнению.

Мне начинает казаться, что Рома и правда подспудно хочет, чтобы его позорище в виде ii забыли и сделали нормально. Хотя, чтобы ii стал полезным, фактически, достаточно было добавить слайсы.

revoltech> А почему так криво задизайнили в 2014 — это уж точно вопрос не ко мне. Но сейчас это приходится принимать как данность. Или же ломать совместимость полностью и делать как следует. Но тогда это уже будет другая сеть.

Будет. И Рома снова придёт со своим нытьём про ii.

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

ahamai> Потому что вы не делали Дизайна проекта, принимая много решений "как поступить"

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

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

Тебе интересно ii. Но это не эхотаг.

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

>> Если у тебя это не так, чини ноду.
ahamai> я не могу починить референсную ii 0.3, которая является базовым и законченным стандартом ii, потому что она осталась в 2014 году

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

ahamai> ps. проблема не в /u/e

Да. Проблема в ii 0.3.

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

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

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

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

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

AL> Всё там же, где он лежит уже чёрт знает сколько лет. Ты же с ним сюда и приходил. Если ты про стандарт ii, то за этим к Роме.

Да я уже запутался. Наверное, про стандарт ii. Короче, про то, что было до ребрендинга в IDEC и появления той доки на гитхабе.

AL> У него должен быть, ведь не может же быть такого, чтобы это великолепие да осталось без описания.

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

Рома, не нервничай. У меня 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 в чистом виде, но тогда и не нервничай. Дай нам двигаться своим путём.

AL>> Всё там же, где он лежит уже чёрт знает сколько лет. Ты же с ним сюда и приходил. Если ты про стандарт ii, то за этим к Роме.
revoltech> Да я уже запутался. Наверное, про стандарт ii. Короче, про то, что было до ребрендинга в IDEC и появления той доки на гитхабе.

Сначала был ii. Вещь хорошая, но недоделка. И даже стандарта не было - был только кривой референсный код. Потом Рома написал что-то типа стандарта. С кучей воды, неоднозначностями и вот это вот всё. Потом мы тут начали думать как ii довести до юзабельного состояния и родили слайсы. Конечно, это плохое решение, но все остальные ещё хуже. Были идеи и со счётчиками (они остались, но ими никто не пользуется, да и выкину я их), с хешем последнего сообщения (вообще максимально плохой вариант), с хешем всего индекса (тоже хреновый вариант, к тому же не позволяет определить откуда качать).

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

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

Скорее всего, так и есть. Но надо спрашивать Рому.

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

Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.

Но сначала актуальный стандарт IDEC реализую в ноде своей, а потом уж посмотрим. Так что там, 40 мессаг на запрос устаканили, больше дополнений к доке не будет, можно приступать к запилу?

revoltech> Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.

Ну я Шаоса, вроде, не тяну. Если кто-то транзитом протащит, затащу к себе.

revoltech> Но сначала актуальный стандарт IDEC реализую в ноде своей, а потом уж посмотрим. Так что там, 40 мессаг на запрос устаканили, больше дополнений к доке не будет, можно приступать к запилу?

Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

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

AL> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.

AL>> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)
hugeping> m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.

Ну m/, по размышлению, мне тоже кажется полезным. Даже просто взять и получить сообщение с помощью curl это удобно. А вот e/ никогда не видел, чтобы использовали. Разве что на заре ещё ii был клиент на баше и dialog, который был онлайн-клиентом и использовал как раз e/ и m/, если мне не изменяет память. Хотя, по факту, разделить строчку и декодировать base64 на баше всё равно просто.

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

AL> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

Согласен.

> Ну я Шаоса, вроде, не тяну.

Ну как не тяну? Тянешь, но по старому списку эх 2021 года и по старому адресу…

Подумал тут ещё... Хочу добавить. Может какой-то мозговой штурм начнётся. Но это все в рамках некоторого "потенциально нового" 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 последнего взятого сообщения для этой ноды.

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

TOP10 VISITORS:

[1] Facebook point=0 web=1027 up=22.9MB (33%)
[2] 176.109.111.x point=46 web=0 up=16.7MB (24%) <--- tavern (2/hr)
[3] 92.63.98.x point=70 web=0 up=5.9MB (8%) <--- tgi (3/hr)
[4] Google point=42 web=480 up=5.7MB (8%) <--- Google (2/hr)
[5] 145.224.100.x point=115 web=1 up=5.0MB (7%) <--- 145.224.100.x (5/hr)
[6] Amazon point=0 web=83 up=4.1MB (5%)
[7] 95.165.9.x point=135 web=2 up=3.3MB (4%) <--- ping (6/hr)
[8] 217.197.116.x point=150 web=0 up=2.7MB (3%) <--- blackcat (6/hr)
[9] 24.130.121.x point=35 web=58 up=2.0MB (2%) <--- spnet (1/hr)
[10] 172.56.42.x point=0 web=35 up=0.2MB (<1%)

TOTAL TRAFFIC: 68MB

Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /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 что думаешь?