Re: Наболтали
Ответ на сообщение
Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.
tuple to shaos (2024-10-28 06:38:32)
[ссылка]
AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.В list.txt счётчик может убывать.
hugeping> А ты знаешь, подумал... Вообще, мне нравится. Без x/c можно жить, тем более если list.txt в базе будет.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Echoareas ──────────────────────── idec.talks...........468 ██████████████████████████████████████████████████▒▒▒▒▒▒▒▒▒ bot.slashdot.........146 ██████████████████████████████████████████████████▒▒ lor.opennet...........61 ██████████████████████████████████████████████████▒ lor.gold..............47 ███████████████████████████████████████████████ idec.test.............35 ███████████████████████████████████ bot.habr.rss..........25 █████████████████████████ linux.14..............18 ██████████████████ bash.rss..............11 ███████████ spnet.stats............7 ███████ ifhub.club.............4 ████ iii.nizya..............2 ██ ii.stat................1 █ bot.antropogenezru.rss.1 █ ──────────────────────── Total 826
shaos>> дык у него ещё нету ноды - тока клиент :)Может и мне что нибудь написать. Хотя это скорее всего будет очередной проект в /projects который я подзаброшу из-за лени или какого-то затыка и когда-то давно вернусь
AL> Вот и повод написать ноду :)
+++ Никто не знает, как правильно. Так зачем же выдумывать правила?
revoltech> Сам же просил все связанные со стандартом вещи начать тегировать как ответы на сабж «Стандарт». Или нет?Ага, теперь понял откуда это. Дело в том, что топики отслеживаются по цепочке repto, а не по subj. Ну, главное теперь я понял, что это не баг.
hugeping> Зачем так делать? :)А началось это кажется здесь: ii://wCtCSY0AQJBPZgD7zwYS
revoltech>> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?Этого пока ничего не надо делать. На днях рожу новый документ, от него и будем плясать.
tuple> В организации значатся двое: difrex (у него была станция, сейчас её нет, давно не видно), btimofeev пару недель назад с ним общались в сети. Зовём его, пусть делает новый репозиторий для Github Pages, туда можно напосылать PR'ов с исправлениями. Но сначала просто полностью скопировать https://github.com/idec-net/new-docs , затем переделать его под Jekyll (чтобы github pages заработал), а только затем посылать всякие исправления и улучшения.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
revoltech>> В extensions.md: написано: «Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii.» — и там перечислен в том числе /list.txt. Это читается так, как будто IDEC от ii отличается в том числе /list.txt, т.е. в ii его не было.Придётся. Раз уж мы тут шатаем то, что есть, то пошатаем и это. Бойтесь :)
hugeping> В ii не было просто самого механизма расширений. В любом случае, смысл менять стандарт я не вижу. Иначе придётся требовать наличия list.txt как обязательного компонента.
revoltech>> А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта.Сейчас всё нормально. Так и оставим по сути.
hugeping> id создаётся один раз в момент создания сообщения, для обмена нет необходимости его где-то пересчитывать. Главное, уникальность. Вероятность коллизии крайне мала, при условии что id считается какой-то хорошей хеш функцией. Хотя, думаю, можно в принципе и тупо рандом брать, думаю на наш век этого точно хватит.
revoltech>> Как и многое другое оттуда же.Голословность как дух времени :)
hugeping> Что именно? x/c - да. msgid - нет, нет такого требования. Хеши и не должны совпадать. Но ты пишешь "многое другое". Где пруфы?
hugeping> Мне кажется ты совсем не читаешь то, что я тебе пишу. Прекращаю это бессмысленное занятие. :)Вообще, надо забыть что это хеш по своему происхождению и постараться вспомнить, что это msgid. Единственная его роль, единственное назначение.
revoltech>> Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.
hugeping> На самом деле с переводами тоже не все просто. Я когда написал фильтр получил ещё несколько сообщений с \r где-то в теле. Я стал их резать при записи в БД. Кстати, ещё один источник того, что хеш может отличаться. В общем, idec и ii не требуют совпадений при пересчёте хеша. Пересчёт вообще не должен нигде проводиться.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
hugeping> Зачем так делать? :)Сам же просил все связанные со стандартом вещи начать тегировать как ответы на сабж «Стандарт». Или нет?
AL> Повод написать :)Напишу. С нексом и слайсами. :) Пока на стадии проектирования.
AL> При этом, если вернулось не 200, то всё идёт лесом до следующего раза.Если вернулось не 200 (имеется в виду ведь хттпшный 200?), то мы в самом начале понимаем, что что-то не то, и размер бандла снова-таки значения не имеет.
AL> Переводы строк могут быть какими угодно. Символ возврата каретки ни на что не влияет.У меня на клиенте не влияет, а у пинга (вроде) на ноде с ними были проблемы.
AL> Ну новый стандарт будет компактный и простой.Это хорошо. Ждём-с.
AL> Жди и всё будет. У меня сейчас не очень простой период в жизни в плане свободного времени.Понимаю, сам вот только недавно из отпуска вышел.
AL> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.А ты знаешь, подумал... Вообще, мне нравится. Без x/c можно жить, тем более если list.txt в базе будет.
hugeping>> Ну, хочется видеть idec другим -- никто не мешает разрабатывать свои варианты...Потому что все хотят менять стандарт или обвешивать его расширениями вместо того, чтобы просто пользоваться :)
tuple> Жаль при этом происходит дробление сообществ на всё более мелкие части...
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
hugeping>> Драматизировать тоже не стоит.Вообще не будет расширений. Будет один стандарт и всё. Расширения на совести людей, их реализующих останутся.
revoltech> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?
revoltech> * Раз GET /list.txt всегда был в ii, надо его описать в базе, а не в расширениях.
revoltech> * Раз айдишники в виде волшебного шопопало до сих пор проскакивают, надо указать, что алгоритм их генерации рекомендован. И указать правила замены на A-z, которые все ноды между собой понимали бы.Алгоритм их генерации не рекомендован, а просто рабочий пример. Все ноды между собой понимают любые замены, так как хеш это просто строка с идентификатором и ничего больше.
revoltech> * Раз счётчики де-факто могут убывать, надо убрать ту приписку «Важно: параметр неубывающий».Это не важно. В новом стандарте счётчиков не будет.
revoltech> Ну и так далее. В общем, привести теоретическую базу к тому, как оно всё на самом деле функционирует. Чтобы новые авторы клиентов (а тем более серверов) не путались в этих трёх соснах как минимум.Ну новый стандарт будет компактный и простой.
revoltech> Я могу выложить свою (англоязычную) доку где-то здесь. Либо в english.talks, либо в какуюто новую эху. Там сейчас базовый ii без расширений по факту. Есть желание привлечь нексовских, гоферистов, джеминистов и прочих активистов смолнета к этой теме, но для начала неплохо было бы довести документацию до удобоваримого вида без разночтений.Жди и всё будет. У меня сейчас не очень простой период в жизни в плане свободного времени.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
revoltech> А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта. А по факту мы видим не то, что там написано.А по факту это всё ни на что не влияет и работает без проблем.
hugeping>> С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.Вот ты дотошный без особого смысла :)
revoltech> Как и многое другое оттуда же.
hugeping>> А что ещё? Ну, переводы строк?Переводы строк могут быть какими угодно. Символ возврата каретки ни на что не влияет.
revoltech> Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
AL>> Твой клиент не работает с твоей нодой?Повод написать :)
revoltech> Моей ноды ещё не существует.
AL>> Что повышает надёжность передачи на нестабильном канале.При этом, если вернулось не 200, то всё идёт лесом до следующего раза.
revoltech> Каким образом, если проверка целостности по msgid, как мы выяснили, идёт лесом, а проверка целостности самого списка в эхе сейчас вообще отсутствует?
revoltech> Ну то есть давай смоделируем ситуацию — обрыв соединения при фетче эхи. Этот обрыв может произойти во время:
revoltech> 1) скачивания списка айдишников в эхе (GET /u/e),
revoltech> 2) скачивания бандла (GET /u/m).
revoltech> В случае номер 1, если обрыв произошёл до последнего известного нам айдишника, мы не знаем, что там между ними (последним известным нам и тем, где произошёл обрыв), поэтому всё равно придётся запрашивать тот же список заново, независимо от размера.
revoltech> В случае номер 2, который на слабом канале критичнее, мы сравниваем список полученных сообщений со списком запрошенных и при несоответствии оных просто перекачиваем с последнего полученного (т.к. его тело могло быть выкачано не полностью). Изначальный размер бандла при этом значения также не имеет.
revoltech> И это ещё с допущением, что само соединение установлено успешно. А чем нестабильнее канал, тем дольше устанавливается соединение. И накладные расходы на кучу мелких запросов в этом случае ещё сильнее влияют.На нестабильном канале выкачать мелкие бандлы более вероятное событие, чем выкачать всё одним бандлом. По крайней мере так показала практика.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
tuple> IDEC протокол нужен только для обсуждения IDEC-реализаций.Можем обсуждать что угодно. Но все предпочитают обсуждать технологию :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
tuple>> IDEC протокол нужен только для обсуждения IDEC-реализаций.IDEC на 100% совместим с ii-0.3. Пользуйся и радуйся жизни.
revoltech> Sad but true. Хотя мне, наверное, было бы достаточно корректно работающего ii. Просто по ходу дела выяснилось, что это ближе к мифу или оксюморону.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
shaos> дык у него ещё нету ноды - тока клиент :)Вот и повод написать ноду :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
AL>> FTN у нас уже есть.Смысла нет :)
doesnm> Сделать гейт в FTN
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
>> Для слайсов количество вообще не обязательно.Да. Не вижу проблемы. Разве что подключения платные и их приходится экономить :)
shaos> т.е. ты предлагаешь каждый раз дёргать каждую эху с параметрами -1:1 чисто на всякий случай? ;)
>> А какой смысл в этом многообразии?Ну тоже вариант. Но на нашей выборке не сработает, скорее всего. Делай как удобнее будет тебе и всего делов :)
shaos> эдакий A/B тест - кто что больше будет использовать, то прилипшим к стене и останется :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
>> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов.Да я что? Я ничего. Так, погулять вышел. Просто надо сильно всех загонять в рамки и часть узлов просто отвалится.
shaos> И каждый раз приходит суровый Andrew Lobanov и ставит фантазёров на место :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
revoltech> В extensions.md: написано: «Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii.» — и там перечислен в том числе /list.txt. Это читается так, как будто IDEC от ii отличается в том числе /list.txt, т.е. в ii его не было.В ii не было просто самого механизма расширений. В любом случае, смысл менять стандарт я не вижу. Иначе придётся требовать наличия list.txt как обязательного компонента.
revoltech> А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта.id создаётся один раз в момент создания сообщения, для обмена нет необходимости его где-то пересчитывать. Главное, уникальность. Вероятность коллизии крайне мала, при условии что id считается какой-то хорошей хеш функцией. Хотя, думаю, можно в принципе и тупо рандом брать, думаю на наш век этого точно хватит.
revoltech> Как и многое другое оттуда же.Что именно? x/c - да. msgid - нет, нет такого требования. Хеши и не должны совпадать. Но ты пишешь "многое другое". Где пруфы?
revoltech> Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.На самом деле с переводами тоже не все просто. Я когда написал фильтр получил ещё несколько сообщений с \r где-то в теле. Я стал их резать при записи в БД. Кстати, ещё один источник того, что хеш может отличаться. В общем, idec и ii не требуют совпадений при пересчёте хеша. Пересчёт вообще не должен нигде проводиться.
tuple> Странно отрабатывает сортировка в профиле https://club.hugeping.ru/from/btimofeev/7 . Если промотать вниз, то там видно два сообщения, которые написаны в 2020-м году, а выше идут из 2024-го.Это следствие того, что эху retro.talks создали только что. Я удалил у себя oldpc и зафетчил retro.talks заново. В итоге, сообщения пришли как бы "только что". Для станции они - новые.
revoltech> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?В организации значатся двое: difrex (у него была станция, сейчас её нет, давно не видно), btimofeev пару недель назад с ним общались в сети. Зовём его, пусть делает новый репозиторий для Github Pages, туда можно напосылать PR'ов с исправлениями. Но сначала просто полностью скопировать https://github.com/idec-net/new-docs , затем переделать его под Jekyll (чтобы github pages заработал), а только затем посылать всякие исправления и улучшения.
hugeping> В стандарте написано что это расширение. Значит - расширение. Было оно в ii или нет, не важно.В extensions.md: написано: «Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii.» — и там перечислен в том числе /list.txt. Это читается так, как будто IDEC от ii отличается в том числе /list.txt, т.е. в ii его не было.
hugeping> Рекомендованный алгоритм описан в стандарте. Но проверять на его соответствие -- в стандарте такого нет. В стандарте указаны не A-z, а A-Z. Но, подумав, не могу сказать что это тоже требует изменения стандарта. Ну, алгоритм отличается немного от ii, и что?А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта. А по факту мы видим не то, что там написано.
hugeping> С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.Как и многое другое оттуда же.
hugeping> А что ещё? Ну, переводы строк?Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.
revoltech> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?Да, я уже предлагал: ii://Z9zSZaq0u1HH47ud8PEz . В ответах предложили поднять на Github Pages на Jekyll, который там есть.
revoltech> * Раз GET /list.txt всегда был в ii, надо его описать в базе, а не в расширениях.В стандарте написано что это расширение. Значит - расширение. Было оно в ii или нет, не важно. Так как стандарт описывает idec. Сейчас ноды написаны так, что декларируют list.txt в расширениях. Для обмена list.txt не является обязательным. Так что не вижу причин переписывать стандарт.
revoltech> * Раз айдишники в виде волшебного шопопало до сих пор проскакивают, надо указать, что алгоритм их генерации рекомендован. И указать правила замены на A-z, которые все ноды между собой понимали бы.Рекомендованный алгоритм описан в стандарте. Но проверять на его соответствие -- в стандарте такого нет. В стандарте указаны не A-z, а A-Z. Но, подумав, не могу сказать что это тоже требует изменения стандарта. Ну, алгоритм отличается немного от ii, и что?
revoltech> * Раз счётчики де-факто могут убывать, надо убрать ту приписку «Важно: параметр неубывающий».С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.
revoltech> Ну и так далее.А что ещё? Ну, переводы строк?