# Re: Стандарт
hugeping (ping,1) → shaos – 09:38:33 2024-10-27
shaos> тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую
Собственно, для этого msgid и нужен. Если ты хочешь на него нагрузить что-то ещё "для красоты", то да, не будет работать редактирование, как минимум. Я понял, что у нас тут разные стремления. Но может быть лучше сделать базовую технологию обмена, а подлинность целостность - это отдельно? Без возможности редактирования сообщений мне ii-go бесполезен. Я ведь использую его для создания заметок. У меня даже резюме лежит на нём. :)
hugeping (ping,1) → shaos – 09:38:33 2024-10-27
shaos> тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую
Собственно, для этого msgid и нужен. Если ты хочешь на него нагрузить что-то ещё "для красоты", то да, не будет работать редактирование, как минимум. Я понял, что у нас тут разные стремления. Но может быть лучше сделать базовую технологию обмена, а подлинность целостность - это отдельно? Без возможности редактирования сообщений мне ii-go бесполезен. Я ведь использую его для создания заметок. У меня даже резюме лежит на нём. :)
# Re: Стандарт
Andrew Lobanov (tavern,1) → shaos – 09:36:06 2024-10-27
shaos> Проблему большого траффика когда тянется всё подряд без оглядки
Эту проблему прекрасно решают слайсы. Посмотри на трафик от Петра. Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 09:36:06 2024-10-27
shaos> Проблему большого траффика когда тянется всё подряд без оглядки
Эту проблему прекрасно решают слайсы. Посмотри на трафик от Петра. Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# RSS-гейт таверны
Andrew Lobanov (tavern,1) → All – 09:24:12 2024-10-27
Починил сабж.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → All – 09:24:12 2024-10-27
Починил сабж.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Стандарт
shaos (spnet, 2) → Andrew Lobanov – 09:22:08 2024-10-27
Проблему большого траффика когда тянется всё подряд без оглядки
shaos (spnet, 2) → Andrew Lobanov – 09:22:08 2024-10-27
Проблему большого траффика когда тянется всё подряд без оглядки
# Re: Стандарт
shaos (spnet, 2) → hugeping – 09:20:40 2024-10-27
тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую, а в ii/IDEC с самого начала (и до сих пор) msgid потенциально пригоден для решения аж 3 задач:
- идентификация уникального сообщения (с высокой степенью защитой от коллизий);
- проверка целостности сообщения (что сообщение не повредилось при передаче от узла где сообщение было принято к узлу где оно читается);
- проверка подлинности сообщения (что зловредные индивиддуумы не подменили источник, приёмник, время, тему ну и до кучи тело сообщения на своё при передаче).
shaos (spnet, 2) → hugeping – 09:20:40 2024-10-27
тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую, а в ii/IDEC с самого начала (и до сих пор) msgid потенциально пригоден для решения аж 3 задач:
- идентификация уникального сообщения (с высокой степенью защитой от коллизий);
- проверка целостности сообщения (что сообщение не повредилось при передаче от узла где сообщение было принято к узлу где оно читается);
- проверка подлинности сообщения (что зловредные индивиддуумы не подменили источник, приёмник, время, тему ну и до кучи тело сообщения на своё при передаче).
# Re: Полуневдимые эхи
Andrew Lobanov (tavern,1) → revoltech – 09:10:48 2024-10-27
revoltech> * длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);
Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.
revoltech> * на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.
Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 09:10:48 2024-10-27
revoltech> * длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);
Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.
revoltech> * на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.
Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Полуневдимые эхи
Andrew Lobanov (tavern,1) → revoltech – 09:10:35 2024-10-27
ahamai>> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то
revoltech> В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.
Почему?
Andrew Lobanov (tavern,1) → revoltech – 09:10:35 2024-10-27
ahamai>> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то
revoltech> В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.
Почему?
# Re: xc: lor
Andrew Lobanov (tavern,1) → revoltech – 09:10:21 2024-10-27
ahamai>> а вообще, у нас сейчас фанаты технологии, но нет фанатов распределённости и локального хранения.
revoltech> Есть. Поэтому все подвижки в сторону «выкачивать не всё и не отовсюду» предлагаю отметать, как вредоносные.
revoltech> В идеале — дайте мне возможность скачать все эхи одним файлом, а дальше уж разберусь локально, что с этим делать.
Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 09:10:21 2024-10-27
ahamai>> а вообще, у нас сейчас фанаты технологии, но нет фанатов распределённости и локального хранения.
revoltech> Есть. Поэтому все подвижки в сторону «выкачивать не всё и не отовсюду» предлагаю отметать, как вредоносные.
revoltech> В идеале — дайте мне возможность скачать все эхи одним файлом, а дальше уж разберусь локально, что с этим делать.
Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Полуневдимые эхи
Andrew Lobanov (tavern,1) → revoltech – 09:10:07 2024-10-27
shaos>> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)
revoltech> Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.
Мы и определились и отказались от максимализма.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 09:10:07 2024-10-27
shaos>> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)
revoltech> Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.
Мы и определились и отказались от максимализма.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: xc: lor
Andrew Lobanov (tavern,1) → ahamai – 09:09:53 2024-10-27
ahamai> Думаю о создании станции lor2ii, которая будет медленно и печально собирать сообщения с текущих тем лора.
ahamai> Без веб интерфейса, либо с веб интерфейсом только для пойнтов.
ahamai> При этом пойнты могут комментировать эти сообщения и они будут доступны другим пойнтам. Получится этакий OverLor.
ahamai> Сообщения с лора тэгировать чем-то типо lorlink/урл-на-сообщение.
ahamai> Вернуть http-клиента и ориентировать на всё это.
ahamai> Кому-нибудь такое интересно?
А чем текущая эха не устраивает? Зачем аж отдельная станция для отдельной эхи?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 09:09:53 2024-10-27
ahamai> Думаю о создании станции lor2ii, которая будет медленно и печально собирать сообщения с текущих тем лора.
ahamai> Без веб интерфейса, либо с веб интерфейсом только для пойнтов.
ahamai> При этом пойнты могут комментировать эти сообщения и они будут доступны другим пойнтам. Получится этакий OverLor.
ahamai> Сообщения с лора тэгировать чем-то типо lorlink/урл-на-сообщение.
ahamai> Вернуть http-клиента и ориентировать на всё это.
ahamai> Кому-нибудь такое интересно?
А чем текущая эха не устраивает? Зачем аж отдельная станция для отдельной эхи?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Полуневдимые эхи
Andrew Lobanov (tavern,1) → doesnm – 09:09:47 2024-10-27
shaos>>> Меньше это Gopher или Nex овер телнет :)
revoltech>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm> Го дропнем base64
Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → doesnm – 09:09:47 2024-10-27
shaos>>> Меньше это Gopher или Nex овер телнет :)
revoltech>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm> Го дропнем base64
Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Полуневдимые эхи
Andrew Lobanov (tavern,1) → revoltech – 09:09:33 2024-10-27
tuple>> Почему жирный-то? Почти натуральный plaintext. Куда меньше?
revoltech> Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.
revoltech> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900
revoltech> Ничего, кроме нетката, телнета или подобного, в основе не требуется.
revoltech> Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:
revoltech> cat <<EOF | nc station.domain 1915
revoltech> /u/point
revoltech> [auth_string]
revoltech> [base64_message]
revoltech> .
revoltech> EOF
revoltech> Вот тут уж действительно меньше некуда.
Ну так пиши транспорт какой тебе больше нравится. Стандарт не завязан на HTTP как таковой. Был опыт обмена и по FTP. Просто HTTP всех устраивает, так как дёшево и просто с точки зрения использования и уже так сложилось.
>> Читать далее
Andrew Lobanov (tavern,1) → revoltech – 09:09:33 2024-10-27
tuple>> Почему жирный-то? Почти натуральный plaintext. Куда меньше?
revoltech> Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.
revoltech> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900
revoltech> Ничего, кроме нетката, телнета или подобного, в основе не требуется.
revoltech> Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:
revoltech> cat <<EOF | nc station.domain 1915
revoltech> /u/point
revoltech> [auth_string]
revoltech> [base64_message]
revoltech> .
revoltech> EOF
revoltech> Вот тут уж действительно меньше некуда.
Ну так пиши транспорт какой тебе больше нравится. Стандарт не завязан на HTTP как таковой. Был опыт обмена и по FTP. Просто HTTP всех устраивает, так как дёшево и просто с точки зрения использования и уже так сложилось.
>> Читать далее
# Re: Стандарт
Andrew Lobanov (tavern,1) → ahamai – 09:09:19 2024-10-27
ahamai> что с лор.опеннетом делать будем?
Чинить. Займусь сегодня.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 09:09:19 2024-10-27
ahamai> что с лор.опеннетом делать будем?
Чинить. Займусь сегодня.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Полуневдимые эхи
Andrew Lobanov (tavern,1) → revoltech – 09:09:12 2024-10-27
AL>> Потому что документация описывает IDEC.
revoltech> Возникает вопрос: её здесь вообще кто-нибудь ещё читал?
И даже писал.
revoltech> Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:
>> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.
revoltech> И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.
Бывает.
revoltech> То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.
Зачем?
>> Читать далее
Andrew Lobanov (tavern,1) → revoltech – 09:09:12 2024-10-27
AL>> Потому что документация описывает IDEC.
revoltech> Возникает вопрос: её здесь вообще кто-нибудь ещё читал?
И даже писал.
revoltech> Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:
>> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.
revoltech> И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.
Бывает.
revoltech> То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.
Зачем?
>> Читать далее
# Re: Стандарт
Andrew Lobanov (tavern,1) → shaos – 09:08:58 2024-10-27
>> ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1
>> Что это должно делать?
shaos> Возвращать хеши эх вместо дескрипшина:
shaos> ====
shaos> idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
shaos> blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
shaos> retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
shaos> bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
shaos> lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
shaos> ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
shaos> lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
shaos> linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz
shaos> ====
Какую проблему это решает?
>> Читать далее
Andrew Lobanov (tavern,1) → shaos – 09:08:58 2024-10-27
>> ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1
>> Что это должно делать?
shaos> Возвращать хеши эх вместо дескрипшина:
shaos> ====
shaos> idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
shaos> blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
shaos> retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
shaos> bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
shaos> lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
shaos> ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
shaos> lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
shaos> linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz
shaos> ====
Какую проблему это решает?
>> Читать далее
# Re: Стандарт
hugeping (ping,1) → hugeping – 08:08:40 2024-10-27
hugeping> Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).
Да, если это прям режет глаз. То можно делать не хеш сообщения. Любой алгоритм генерации uuid. Например, хеш от времени в мс + имя системы...
P.S. Edited: 2024-10-27 08:08:47
hugeping (ping,1) → hugeping – 08:08:40 2024-10-27
hugeping> Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).
Да, если это прям режет глаз. То можно делать не хеш сообщения. Любой алгоритм генерации uuid. Например, хеш от времени в мс + имя системы...
P.S. Edited: 2024-10-27 08:08:47
# Re: Полуневдимые эхи
shaos (spnet, 2) → revoltech – 08:16:35 2024-10-27
А ну если ты только про своего клиента, то ок
Главное если надумаешь делать свой узел, чтобы он умел слайсы ;)
shaos (spnet, 2) → revoltech – 08:16:35 2024-10-27
А ну если ты только про своего клиента, то ок
Главное если надумаешь делать свой узел, чтобы он умел слайсы ;)
# Re: Стандарт
hugeping (ping,1) → Andrew Lobanov – 08:02:08 2024-10-27
Тут опять хаос с топиками. Я буду всегда отвечать в топике "Стандарт" для порядка. Появились такие мысли:
1) Хеши в list.txt мне не нравятся потому, что list.txt на данный момент не является обязательным и выглядит как просто информационный. Почему бы, если уж делать хеши эх, не сделать что-то вроде /u/h/ ? Использование хешей именно в list.txt да ещё и в позициях дескрипшена - выглядит как хак.
2) x/c считаю должен отражать реальный счётчик сообщений для просмотра "на лету" совместно со слайсами. Либо да, убирать и слайсы и x/c
3) Редактирование сообщений это не только "в последний момент" поменять что-то. Это вполне себе необходимая вещь, если мы рассматриваем idec не просто как болталку. Например, есть статья я её редактирую. Ссылка на статью должна быть постоянной... Для контента это важно.
Так, вот, если мы говорим, что хеши (или другой механизм, который позволяет отследить необходимость фетча) используется только совместно с полным фетчем эхи, то проблему редактирования можно в принципе решить относительно элегантно. Например:
MsgId делится на две части. 1-я - собственно ID (изначально считается как хеш) и счётчик изменений, который всегда увеличивается на 1. Гарантируется что в базе ID всегда уникальны и у нас нет двух сообщений с одинаковым ID, но разными счётчиками. При работе с сообщениями в системе мы в целом пользуемся ID, а счётчик изменений используем при фетче если нужно "обновить" отредактированное сообщение.
Ну что то вроде: IIIIIIIIIIIIIIIIrrrr. I - хеш, rrrr - закодированный номер изменений. А может и не закодированный а прямо: 1t0CZs5lzqVxsoht0001
Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).
hugeping (ping,1) → Andrew Lobanov – 08:02:08 2024-10-27
Тут опять хаос с топиками. Я буду всегда отвечать в топике "Стандарт" для порядка. Появились такие мысли:
1) Хеши в list.txt мне не нравятся потому, что list.txt на данный момент не является обязательным и выглядит как просто информационный. Почему бы, если уж делать хеши эх, не сделать что-то вроде /u/h/ ? Использование хешей именно в list.txt да ещё и в позициях дескрипшена - выглядит как хак.
2) x/c считаю должен отражать реальный счётчик сообщений для просмотра "на лету" совместно со слайсами. Либо да, убирать и слайсы и x/c
3) Редактирование сообщений это не только "в последний момент" поменять что-то. Это вполне себе необходимая вещь, если мы рассматриваем idec не просто как болталку. Например, есть статья я её редактирую. Ссылка на статью должна быть постоянной... Для контента это важно.
Так, вот, если мы говорим, что хеши (или другой механизм, который позволяет отследить необходимость фетча) используется только совместно с полным фетчем эхи, то проблему редактирования можно в принципе решить относительно элегантно. Например:
MsgId делится на две части. 1-я - собственно ID (изначально считается как хеш) и счётчик изменений, который всегда увеличивается на 1. Гарантируется что в базе ID всегда уникальны и у нас нет двух сообщений с одинаковым ID, но разными счётчиками. При работе с сообщениями в системе мы в целом пользуемся ID, а счётчик изменений используем при фетче если нужно "обновить" отредактированное сообщение.
Ну что то вроде: IIIIIIIIIIIIIIIIrrrr. I - хеш, rrrr - закодированный номер изменений. А может и не закодированный а прямо: 1t0CZs5lzqVxsoht0001
Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).
# Re: Полуневдимые эхи
revoltech (spnet, 4) → shaos – 07:54:57 2024-10-27
shaos> а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...
Ну я у себя теперь просто делаю приписку (ID hash mismatch!) рядом с айдишником у таких сообщений.
revoltech (spnet, 4) → shaos – 07:54:57 2024-10-27
shaos> а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...
Ну я у себя теперь просто делаю приписку (ID hash mismatch!) рядом с айдишником у таких сообщений.
# Re: Полуневдимые эхи
revoltech (spnet, 4) → shaos – 07:52:44 2024-10-27
shaos> не будем забывать про слабые ретроплатформы где память 64КБ и меньше
А на такие платформы уже портировали Tcl 8.6, sqlite3 и прочее? Я же конкретно насчёт своего клиента/фетчера говорю. Там-то понятное дело, что другие подходы ко всему нужны.
shaos> и потом возможность создания "листающих" клиентов, как было описано чуть ранее, должна оставаться, т.е. слайсы выкидывать ненадо...
Да я не против того, чтобы в стандарте они оставались.
revoltech (spnet, 4) → shaos – 07:52:44 2024-10-27
shaos> не будем забывать про слабые ретроплатформы где память 64КБ и меньше
А на такие платформы уже портировали Tcl 8.6, sqlite3 и прочее? Я же конкретно насчёт своего клиента/фетчера говорю. Там-то понятное дело, что другие подходы ко всему нужны.
shaos> и потом возможность создания "листающих" клиентов, как было описано чуть ранее, должна оставаться, т.е. слайсы выкидывать ненадо...
Да я не против того, чтобы в стандарте они оставались.
# Re: Полуневдимые эхи
shaos (spnet, 2) → revoltech – 06:28:24 2024-10-27
> длина файла с айдишниками эхи не настолько велика
не будем забывать про слабые ретроплатформы где память 64КБ и меньше
например список хешей lor-openned.17 весит 299КБ и они точно не влезут в память ретрокомпьютера целиком
и потом возможность создания "листающих" клиентов, как было описано чуть ранее, должна оставаться, т.е. слайсы выкидывать ненадо...
shaos (spnet, 2) → revoltech – 06:28:24 2024-10-27
> длина файла с айдишниками эхи не настолько велика
не будем забывать про слабые ретроплатформы где память 64КБ и меньше
например список хешей lor-openned.17 весит 299КБ и они точно не влезут в память ретрокомпьютера целиком
и потом возможность создания "листающих" клиентов, как было описано чуть ранее, должна оставаться, т.е. слайсы выкидывать ненадо...
# Re: Полуневдимые эхи
shaos (spnet, 2) → revoltech – 05:53:24 2024-10-27
> айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);
ну почему не может? может
просто на новых узлах можно завести специальный атрибут у некоторых эх типа принимать только валидные сообщения ( там где это будет действительно нужно - типа idec.coin ; )
а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...
shaos (spnet, 2) → revoltech – 05:53:24 2024-10-27
> айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);
ну почему не может? может
просто на новых узлах можно завести специальный атрибут у некоторых эх типа принимать только валидные сообщения ( там где это будет действительно нужно - типа idec.coin ; )
а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...
# Re: Полуневдимые эхи
revoltech (spnet, 4) → shaos – 05:28:56 2024-10-27
В сухом остатке _на данный момент_ имеем следующее:
* айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);
* длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);
* на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.
revoltech (spnet, 4) → shaos – 05:28:56 2024-10-27
В сухом остатке _на данный момент_ имеем следующее:
* айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);
* длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);
* на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.
# Re: Полуневдимые эхи
shaos (spnet, 2) → revoltech – 05:15:57 2024-10-27
> Что есть маразм by design. Хэш — он на то и хэш
с одной стороны редактирование мессаджей это местная самодеятельность (типа ой, я тут запятую забыл поставить, дай ка побырому исправлю пока мессага не зафетчилась другими узлами) т.е. by design таки подразумевалось, что мессаги не редактируются
с другой стороны заявляется использование хешей только для обеспечения уникальности имён файлов сообщений, но не для проверки целостности или подлинности самих сообщений и этот момент мне непонятен т.к. для целостности и подлинности по сути ничего добавлять ненадо - всё уже есть (просто чётко прописываем в стандарте правила хеширования с примерами и запрещаем редактирование уже принятых узлом сообщений - опять же на уровне стандарта)
P.S. хеш с подменой двух небуквоциферных символов в хеше на A и z по идее можно и оставить как рудимент прошлого т.к. оно даёт возможность по статистическому анализу букв используемых среди N хешей со 100% уверенностью сказать, что они пришли из ii/IDEC-сетей ;)
shaos (spnet, 2) → revoltech – 05:15:57 2024-10-27
> Что есть маразм by design. Хэш — он на то и хэш
с одной стороны редактирование мессаджей это местная самодеятельность (типа ой, я тут запятую забыл поставить, дай ка побырому исправлю пока мессага не зафетчилась другими узлами) т.е. by design таки подразумевалось, что мессаги не редактируются
с другой стороны заявляется использование хешей только для обеспечения уникальности имён файлов сообщений, но не для проверки целостности или подлинности самих сообщений и этот момент мне непонятен т.к. для целостности и подлинности по сути ничего добавлять ненадо - всё уже есть (просто чётко прописываем в стандарте правила хеширования с примерами и запрещаем редактирование уже принятых узлом сообщений - опять же на уровне стандарта)
P.S. хеш с подменой двух небуквоциферных символов в хеше на A и z по идее можно и оставить как рудимент прошлого т.к. оно даёт возможность по статистическому анализу букв используемых среди N хешей со 100% уверенностью сказать, что они пришли из ii/IDEC-сетей ;)
# Re: Полуневдимые эхи
revoltech (spnet, 4) → ahamai – 04:59:39 2024-10-27
ahamai> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то
В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.
revoltech (spnet, 4) → ahamai – 04:59:39 2024-10-27
ahamai> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то
В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.