subject: Стандарт
25.10.2024 19:26
Andrew Lobanov (tavern,1)
Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.
Вредоносные вещи, типа эх только для чтения, кармы и прочих извращений щитвеба не пущать.
Продумать систему наказаний поинтов (накопление плюсиков, перевод в "только чтения", отключение от эхи) на уровне стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 20:01
shaos (spnet, 2) => 1t0CZs5lzqVxsohtOvjd
а количество плюсиков не равно обратной карме? ;)
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 19:41
ahamai (blackcat, 2) => 1t0CZs5lzqVxsohtOvjd
предлагаю включить в стандарт возможность исполнения list.txt?h=1
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 20:34
hugeping (ping,1) => 1t0CZs5lzqVxsohtOvjd
AL> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики
Я тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть:
1) получили счётчики
2) нарисовали пагинатор
3) по мере "листания" пользователя - проходим сообщения слайсами
Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.
P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 20:51
hugeping (ping,1) => kudeudPOBGomU4WcnJA9
ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1
А что это значит, напомни?
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 20:54
ahamai (blackcat, 2) => CmrT5oHudrn4vy45mMIB
клиент, просматривающий сообщения онлайн, без слайсов и прочего
====
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 :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 21:09
ahamai (blackcat, 2) => 9xnBcvBWu2AoSSHLl810
http://ii.blcat.ru/list.txt?h=1
заменяет описание хэшем эхи. чтобы отслеживать, какие эхи изменились а какие нет, легко реализуется, понятно и прозрачно
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 21:58
shaos (spnet, 2) => ceNdJWETgb9ZVUuHnFzd
Даже пример реализации пролетал :)
https://github.com/gk11-ru/ii-elp/blob/master/run.py#L24
Сегодня-завтра попробую у себя добавить
Плюс listhsh.txt как алиас того же самого плюс /x/h который как /x/c но вместо номеров - хеши хешей
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 22:06
hugeping (ping,1) => AzEKNFNpurv23LLsbzav
shaos> Даже пример реализации пролетал :)
Мне идея хешей эх не нравится. Придётся хранить состояние последнее на диске при фетче. Теряется эстетика простоты. Кроме того, сплайсы и так решают эту проблему (но более элегантно). В общем я понял, стандарт лучше не трогать!
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 22:14
ahamai (blackcat, 2) => KXRoPWMGIhX3ZaNEEtd0
> Мне идея хешей эх не нравится.
ну это самый надёжный способ показать, изменилась эха или нет. только два состояния, эха изменилась и эха не изменилась. изменилась фетчим, не изменилась не фетчим. две строки кода для сервера и несколько строк для фетчера
> Придётся хранить состояние последнее на диске при фетче.
хранить предыдущий list.txt, только и всего. зато меньше лишних запросов, большинство эх перманентно мёртвые. я жду, когда shaos сделает ?h=1, чтобы под это фетчеры адаптировать и не гонять лишнее.
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 23:06
Andrew Lobanov (tavern,1) => HfGOSmmEuv0lGI44F20z
shaos> а количество плюсиков не равно обратной карме? ;)
Нет :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 23:06
Andrew Lobanov (tavern,1) => kudeudPOBGomU4WcnJA9
ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1
Что это должно делать?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
25.10.2024 23:06
Andrew Lobanov (tavern,1) => CmrT5oHudrn4vy45mMIB
AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики
hugeping> Я тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть:
hugeping> 1) получили счётчики
hugeping> 2) нарисовали пагинатор
hugeping> 3) по мере "листания" пользователя - проходим сообщения слайсами
hugeping> Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.
Мысль интересная, но я бы за такие манипуляции со своей станцией карал :)
hugeping> P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....
Там они показывают фактическое количество сообщений. То есть могут иметь отрицательный рост :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
26.10.2024 00:17
shaos (spnet, 2) => YA6ymlO22WZVg5mOcSLp
>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
====
--------------------------------------------------------------------------------
subject: Re: Стандарт
26.10.2024 02:17
ahamai (blackcat, 2) => oKCeD3vEJ7f3kQKE2a2F
что с лор.опеннетом делать будем?
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 11:02
hugeping (ping,1) => 1t0CZs5lzqVxsohtOvjd
Тут опять хаос с топиками. Я буду всегда отвечать в топике "Стандарт" для порядка. Появились такие мысли:
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 сообщения, не обязан совпадать при перерасчёте (он и не будет).
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 11:08
hugeping (ping,1) => sZbskcy7huzEVJlsSDIF
hugeping> Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).
Да, если это прям режет глаз. То можно делать не хеш сообщения. Любой алгоритм генерации uuid. Например, хеш от времени в мс + имя системы...
P.S. Edited: 2024-10-27 08:08:47
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 12:08
Andrew Lobanov (tavern,1) => oKCeD3vEJ7f3kQKE2a2F
>> 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> ====
Какую проблему это решает?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 12:09
Andrew Lobanov (tavern,1) => hV5mgizMr9I1Y8Bxy9R2
ahamai> что с лор.опеннетом делать будем?
Чинить. Займусь сегодня.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 12:20
shaos (spnet, 2) => GoiZDsUQxbZbGgRp02Zw
тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую, а в ii/IDEC с самого начала (и до сих пор) msgid потенциально пригоден для решения аж 3 задач:
- идентификация уникального сообщения (с высокой степенью защитой от коллизий);
- проверка целостности сообщения (что сообщение не повредилось при передаче от узла где сообщение было принято к узлу где оно читается);
- проверка подлинности сообщения (что зловредные индивиддуумы не подменили источник, приёмник, время, тему ну и до кучи тело сообщения на своё при передаче).
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 12:22
shaos (spnet, 2) => l2OQSHfkevLtVUKfedOR
Проблему большого траффика когда тянется всё подряд без оглядки
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 12:36
Andrew Lobanov (tavern,1) => PxKqlpb3L9ANYrpcU1Yw
shaos> Проблему большого траффика когда тянется всё подряд без оглядки
Эту проблему прекрасно решают слайсы. Посмотри на трафик от Петра. Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 12:38
hugeping (ping,1) => MeQskUzPKQgAWrgfWNMY
shaos> тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую
Собственно, для этого msgid и нужен. Если ты хочешь на него нагрузить что-то ещё "для красоты", то да, не будет работать редактирование, как минимум. Я понял, что у нас тут разные стремления. Но может быть лучше сделать базовую технологию обмена, а подлинность целостность - это отдельно? Без возможности редактирования сообщений мне ii-go бесполезен. Я ведь использую его для создания заметок. У меня даже резюме лежит на нём. :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 13:12
shaos (spnet, 2) => LK1aBwPDsNBgO9yRTGyI
> shaos> Проблему большого траффика когда тянется всё подряд без оглядки
> Эту проблему прекрасно решают слайсы.
Ну будут решать ещё лучше, когда необходимость дёргания будет решаться не по количеству сообщений в эхе, а по хешу т.к. например в ii-php количество сообщений это реальное количество сообщений в эхе и в /list.txt, и в /x/c (т.е. оно может не только расти, но и уменьшатся, и даже оставаться неизменным когда убавилось столько же сообщений сколько и добавилось, но этого никто не заметил т.к. сравнивают номера).
> Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?
Обычный /list.txt останется как был, а для хешей я пока делаю на выбор:
/list.txt?h=1
/listhsh.txt
и по аналогии с /x/c будет /x/h но вместо количества сообщений там будут хеши
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 13:15
shaos (spnet, 2) => f5dWhdzXnZrthhmr7KmA
А зачем отдельно, если оно уже есть - никаких новых полей ненадо т.к. всё уже прям тут - бери и используй как говорится :)
И потом я же не предлагаю всё ломать - кто-то будет использовать msgid для проверки целостности, а кто-то нет (я вообще думаю у себя по эхам это сделать - где то показывать неправильные сообщения другим цветом или с другим фоном, а где-то просто отбрасывать как потенциально вредные).
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 13:31
hugeping (ping,1) => Us1o8Iwhk5W5l80air2m
shaos> А зачем отдельно, если оно уже есть - никаких новых полей ненадо т.к. всё уже прям тут - бери и используй как говорится :)
Я там выше сообщение написал про то как можно сделать редактирование. ii://sZbskcy7huzEVJlsSDIF
То-есть, если считаем msgid настоящим хешем, так уже не сделать.
Мне интереснее, конечно, эту проблему решить.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 13:27
Andrew Lobanov (tavern,1) => f5dWhdzXnZrthhmr7KmA
shaos>> тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую
hugeping> Собственно, для этого msgid и нужен. Если ты хочешь на него нагрузить что-то ещё "для красоты", то да, не будет работать редактирование, как минимум. Я понял, что у нас тут разные стремления. Но может быть лучше сделать базовую технологию обмена, а подлинность целостность - это отдельно? Без возможности редактирования сообщений мне ii-go бесполезен. Я ведь использую его для создания заметок. У меня даже резюме лежит на нём. :)
Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов. Я тоже предвзято отношусь к редактированию сообщений, но исключительно потому, что это ломает обмен. Получается, что на разных узлах лежат разные версии одного и того же сообщения.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 13:48
revoltech (spnet, 4) => 367LiUQAXz1NAs7CA7BM
AL> Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.
Внезапно, я сам в селе. Интернет спутниковый.
По поводу слайсов на своём клиенте пока окончательно не решил. В принципе, для тестирования симулировать медленный трафик довольно легко: достаточно делать фетч через torsocks.
AL> Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.
Сделаю. Клиент tii (а конкретнее — компонент tiifetch), собственно, уже поддерживает выкачивание по гоферу, нексу, спартану и джемини. Не на чем только это всё потестить покамест.
AL> Почему?
А кто её передаст, точку эту?
AL> Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.
Вот для первого выкачивания такая опция не помешала бы. Иначе ему придётся качать те же несколько сотен мегабайт, но маленькими фрагментами.
AL> Мы и определились и отказались от максимализма.
Вместе с минимализмом.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:09
hugeping (ping,1) => oUIFqlVRlvhJe17swAz0
AL> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов. Я тоже предвзято отношусь к редактированию сообщений, но исключительно потому, что это ломает обмен. Получается, что на разных узлах лежат разные версии одного и того же сообщения.
Да, я там сделал попытку предложить что-то (как мысленный эксперимент): ii://sZbskcy7huzEVJlsSDIF
Вроде в таком варианте новые версии сообщения будут распространяться.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:24
shaos (spnet, 2) => 0Lo8T5IAlUzzV0A2pgzy
опиши подробнее как по нексу планиуешь работать - я подниму сервачок :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:26
shaos (spnet, 2) => oUIFqlVRlvhJe17swAz0
> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов.
И каждый раз приходит суровый Andrew Lobanov и ставит фантазёров на место :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:28
hugeping (ping,1) => 5JheH8Fgky2U05ICOHZX
hugeping> Да, я там сделал попытку предложить что-то (как мысленный эксперимент): ii://sZbskcy7huzEVJlsSDIF
hugeping> Вроде в таком варианте новые версии сообщения будут распространяться.
То-есть, основные мысли:
1) если видим что что-то на станции в этой эхе поменялось - всегда делаем полный фетч (адаптивный фетч в топку)
2) во время фетча учитываем не только id, но и ревизию сообщения. Всё это для простоты может быть частью msgid (но может и не быть)
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:21
Andrew Lobanov (tavern,1) => d1YtjJH9g40Ihge7F1Mu
>> shaos> Проблему большого траффика когда тянется всё подряд без оглядки
>> Эту проблему прекрасно решают слайсы.
shaos> Ну будут решать ещё лучше, когда необходимость дёргания будет решаться не по количеству сообщений в эхе, а по хешу т.к. например в ii-php количество сообщений это реальное количество сообщений в эхе и в /list.txt, и в /x/c (т.е. оно может не только расти, но и уменьшатся, и даже оставаться неизменным когда убавилось столько же сообщений сколько и добавилось, но этого никто не заметил т.к. сравнивают номера).
Для слайсов количество вообще не обязательно.
>> Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?
shaos> Обычный /list.txt останется как был, а для хешей я пока делаю на выбор:
shaos> /list.txt?h=1
shaos> /listhsh.txt
shaos> и по аналогии с /x/c будет /x/h но вместо количества сообщений там будут хеши
А какой смысл в этом многообразии?
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:22
Andrew Lobanov (tavern,1) => 0Lo8T5IAlUzzV0A2pgzy
AL>> Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.
revoltech> Внезапно, я сам в селе. Интернет спутниковый.
Это что-то на богатом.
AL>> Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.
revoltech> Сделаю. Клиент tii (а конкретнее — компонент tiifetch), собственно, уже поддерживает выкачивание по гоферу, нексу, спартану и джемини. Не на чем только это всё потестить покамест.
Твой клиент не работает с твоей нодой?
AL>> Почему?
revoltech> А кто её передаст, точку эту?
Твоя нода на новом транспорте?
AL>> Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.
revoltech> Вот для первого выкачивания такая опция не помешала бы. Иначе ему придётся качать те же несколько сотен мегабайт, но маленькими фрагментами.
Что повышает надёжность передачи на нестабильном канале.
AL>> Мы и определились и отказались от максимализма.
revoltech> Вместе с минимализмом.
Всё так. От крайностей одни неприятности.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:38
shaos (spnet, 2) => OFospq0ndvqkEj0oeegY
лучше версионность делать иными средствами имхо - поверх и сбоку т.к. оно будет нужно только для очень особенного типа сообщений - формирователей контента (я тоже недавно думал про что-то такое для управлением статическим веб-сайтом, который строится из кирпичиков, которые засылаются через ii)
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:40
shaos (spnet, 2) => JMBNCpA90opTfZi8VI1r
дык у него ещё нету ноды - тока клиент :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:42
shaos (spnet, 2) => SW42NfIlMHX7pAwkkHrv
> Для слайсов количество вообще не обязательно.
т.е. ты предлагаешь каждый раз дёргать каждую эху с параметрами -1:1 чисто на всякий случай? ;)
> А какой смысл в этом многообразии?
эдакий A/B тест - кто что больше будет использовать, то прилипшим к стене и останется :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:47
hugeping (ping,1) => JOHemYNZRC8Uo9QwAYQU
shaos> лучше версионность делать иными средствами имхо - поверх и сбоку
Вот и проверку подлинности можно поверх и сборку. :)
Кроме шуток, да, я думал о "сбоку". Но тогда, получается, мы должны сначала получить id сообщений эхи. А потом, ревизии но в полном соответствии с id. И тогда непонятно вообще зачем 1й вызов? Ну то-есть оно может быть сбоку, да, но ответ всё равно будет включать в себя и id и rev. Ну например:
JOHemYNZRC8Uo9QwAYQU:1
Мне кажется редактирование сообщений неплохо в "базе" иметь, всё-таки.
> т.к. оно будет нужно только для очень особенного типа сообщений
Понимаешь, у всех у нас своё "особенное" понимание. Я считаю что ii следует понимать просто как распространение текстовых сообщений. Что ИМЕННО в этих текстовых сообщениях - не наше дело. Кто-то считает, что это "мессенджер", кто-то - форум, а кто-то в блогах пишет....
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 14:49
hugeping (ping,1) => eKEk4nivUUl1Wn6yw2Ec
hugeping> JOHemYNZRC8Uo9QwAYQU:1
Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 15:02
revoltech (spnet, 4) => JMBNCpA90opTfZi8VI1r
AL> Твой клиент не работает с твоей нодой?
Моей ноды ещё не существует.
AL> Что повышает надёжность передачи на нестабильном канале.
Каким образом, если проверка целостности по msgid, как мы выяснили, идёт лесом, а проверка целостности самого списка в эхе сейчас вообще отсутствует?
Ну то есть давай смоделируем ситуацию — обрыв соединения при фетче эхи. Этот обрыв может произойти во время:
1) скачивания списка айдишников в эхе (GET /u/e),
2) скачивания бандла (GET /u/m).
В случае номер 1, если обрыв произошёл до последнего известного нам айдишника, мы не знаем, что там между ними (последним известным нам и тем, где произошёл обрыв), поэтому всё равно придётся запрашивать тот же список заново, независимо от размера.
В случае номер 2, который на слабом канале критичнее, мы сравниваем список полученных сообщений со списком запрошенных и при несоответствии оных просто перекачиваем с последнего полученного (т.к. его тело могло быть выкачано не полностью). Изначальный размер бандла при этом значения также не имеет.
И это ещё с допущением, что само соединение установлено успешно. А чем нестабильнее канал, тем дольше устанавливается соединение. И накладные расходы на кучу мелких запросов в этом случае ещё сильнее влияют.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 15:05
revoltech (spnet, 4) => IkDuJtl3XezTnBArXloU
shaos> опиши подробнее как по нексу планиуешь работать - я подниму сервачок :)
Ну геты с порта 1900 точно так же, как в хттп (просто путь в сокет, \n и забираем ответ), а посты по порту 1915 — каноничная NPS-форма такова:
cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 15:34
hugeping (ping,1) => u8M1AUKXkDKoSpQb6myh
hugeping>> JOHemYNZRC8Uo9QwAYQU:1
hugeping> Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.
Гм. На практике, редактирование сообщения - добавление новой записи в бд. Так что тут не все так просто.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 15:39
hugeping (ping,1) => Hi2sV6bRurcXgmlVelex
hugeping>>> JOHemYNZRC8Uo9QwAYQU:1
hugeping>> Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.
hugeping> Гм. На практике, редактирование сообщения - добавление новой записи в бд. Так что тут не все так просто.
Да нет, вроде нормально... Редактирование сообщения - это выпуск msgid с новым полем rev. Это на усмотрение ноды как именно отразить это в бд. В ii-go это дописывание новой инфы которая "перекрывает" старую. В sql это может быть тупо запись в бд. Требовать чтобы запись добавилась в конец запроса u/e наверное нецелесообразно.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 16:05
shaos (spnet, 2) => LgIACIcjgMmZBEEbws86
а почему бы и не добавлять также как в хттп?
/u/point/pauth/tmsg
\n и забираем ответ
или там ограничение на длину запроса?...
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 16:12
revoltech (spnet, 4) => s3HI9AVpsvjX3EtIdLnO
shaos> а почему бы и не добавлять также как в хттп?
shaos>
shaos> /u/point/pauth/tmsg
shaos>
shaos> \n и забираем ответ
shaos>
shaos> или там ограничение на длину запроса?...
Нет, как раз в нексе в спецификации ([1]) ограничения на запрос нет, можно и так и по тому же порту. По NPS ([2]) идиоматичнее просто.
Но, в принципе, да, можно и портом 1900 по предложенному тобой варианту обойтись, наверное.
[1]: https://nightfall.city/nex/info/specification.txt
[2]: https://nightfall.city/nps/info/form.txt
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 16:14
shaos (spnet, 2) => eKEk4nivUUl1Wn6yw2Ec
> Понимаешь, у всех у нас своё "особенное" понимание. Я считаю что ii следует понимать просто как распространение текстовых сообщений. Что ИМЕННО в этих текстовых сообщениях - не наше дело. Кто-то считает, что это "мессенджер", кто-то - форум, а кто-то в блогах пишет....
Ну вот поэтому все редакции "особых" сообщений должны идти как отдельные записи в списке хешей (причём корректно посчитанных) - протокол ii будет честно доставлять их все (вдруг мы захотим откатиться), НО отдельно могут идти системные сообщения для некоей CMS внутри которых неким айдишникам кирпичиков (которые не меняются) будут ставится в соответствие хэши новых редакций - вобщем как-то так
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 16:24
shaos (spnet, 2) => ceNdJWETgb9ZVUuHnFzd
Всё сделал - проверяй :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 16:31
hugeping (ping,1) => o002EmNbMGYYNSOuRG3p
shaos> Ну вот поэтому все редакции "особых" сообщений должны идти как отдельные записи в списке хешей
Это слишком сложно и нецельно. Ладно, я тогда не буду развивать тему. Существующий стандарт хотя бы какая-то твердая почва
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 19:25
revoltech (spnet, 4) => rgxK6d4FLFZpuzawHltM
hugeping> В стандарте написано что это расширение. Значит - расширение. Было оно в ii или нет, не важно.
В extensions.md: написано: «Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii.» — и там перечислен в том числе /list.txt. Это читается так, как будто IDEC от ii отличается в том числе /list.txt, т.е. в ii его не было.
hugeping> Рекомендованный алгоритм описан в стандарте. Но проверять на его соответствие -- в стандарте такого нет. В стандарте указаны не A-z, а A-Z. Но, подумав, не могу сказать что это тоже требует изменения стандарта. Ну, алгоритм отличается немного от ii, и что?
А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта. А по факту мы видим не то, что там написано.
hugeping> С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.
Как и многое другое оттуда же.
hugeping> А что ещё? Ну, переводы строк?
Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 19:53
Andrew Lobanov (tavern,1) => 5Q7CW9VaVfbqEDIJkAJR
>> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов.
shaos> И каждый раз приходит суровый Andrew Lobanov и ставит фантазёров на место :)
Да я что? Я ничего. Так, погулять вышел. Просто надо сильно всех загонять в рамки и часть узлов просто отвалится.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 19:53
Andrew Lobanov (tavern,1) => VNVmnMjy3pQlgaz6VcLj
shaos> дык у него ещё нету ноды - тока клиент :)
Вот и повод написать ноду :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 19:53
Andrew Lobanov (tavern,1) => Bz8XWzLP0LZhZTBndzwk
>> Для слайсов количество вообще не обязательно.
shaos> т.е. ты предлагаешь каждый раз дёргать каждую эху с параметрами -1:1 чисто на всякий случай? ;)
Да. Не вижу проблемы. Разве что подключения платные и их приходится экономить :)
>> А какой смысл в этом многообразии?
shaos> эдакий A/B тест - кто что больше будет использовать, то прилипшим к стене и останется :)
Ну тоже вариант. Но на нашей выборке не сработает, скорее всего. Делай как удобнее будет тебе и всего делов :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 19:53
Andrew Lobanov (tavern,1) => qnbrVRPSydMsg2TlAjIg
AL>> Твой клиент не работает с твоей нодой?
revoltech> Моей ноды ещё не существует.
Повод написать :)
AL>> Что повышает надёжность передачи на нестабильном канале.
revoltech> Каким образом, если проверка целостности по msgid, как мы выяснили, идёт лесом, а проверка целостности самого списка в эхе сейчас вообще отсутствует?
revoltech> Ну то есть давай смоделируем ситуацию — обрыв соединения при фетче эхи. Этот обрыв может произойти во время:
revoltech> 1) скачивания списка айдишников в эхе (GET /u/e),
revoltech> 2) скачивания бандла (GET /u/m).
revoltech> В случае номер 1, если обрыв произошёл до последнего известного нам айдишника, мы не знаем, что там между ними (последним известным нам и тем, где произошёл обрыв), поэтому всё равно придётся запрашивать тот же список заново, независимо от размера.
revoltech> В случае номер 2, который на слабом канале критичнее, мы сравниваем список полученных сообщений со списком запрошенных и при несоответствии оных просто перекачиваем с последнего полученного (т.к. его тело могло быть выкачано не полностью). Изначальный размер бандла при этом значения также не имеет.
При этом, если вернулось не 200, то всё идёт лесом до следующего раза.
revoltech> И это ещё с допущением, что само соединение установлено успешно. А чем нестабильнее канал, тем дольше устанавливается соединение. И накладные расходы на кучу мелких запросов в этом случае ещё сильнее влияют.
На нестабильном канале выкачать мелкие бандлы более вероятное событие, чем выкачать всё одним бандлом. По крайней мере так показала практика.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 19:53
Andrew Lobanov (tavern,1) => wCtCSY0AQJBPZgD7zwYS
revoltech> А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта. А по факту мы видим не то, что там написано.
А по факту это всё ни на что не влияет и работает без проблем.
hugeping>> С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.
revoltech> Как и многое другое оттуда же.
Вот ты дотошный без особого смысла :)
hugeping>> А что ещё? Ну, переводы строк?
revoltech> Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.
Переводы строк могут быть какими угодно. Символ возврата каретки ни на что не влияет.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 19:53
hugeping (ping,1) => wCtCSY0AQJBPZgD7zwYS
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 не требуют совпадений при пересчёте хеша. Пересчёт вообще не должен нигде проводиться.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 20:20
hugeping (ping,1) => 1t0CZs5lzqVxsohtOvjd
AL> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.
А ты знаешь, подумал... Вообще, мне нравится. Без x/c можно жить, тем более если list.txt в базе будет.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 20:23
revoltech (spnet, 4) => P6SncwFWkoURHepHYYFd
AL> Повод написать :)
Напишу. С нексом и слайсами. :) Пока на стадии проектирования.
AL> При этом, если вернулось не 200, то всё идёт лесом до следующего раза.
Если вернулось не 200 (имеется в виду ведь хттпшный 200?), то мы в самом начале понимаем, что что-то не то, и размер бандла снова-таки значения не имеет.
AL> Переводы строк могут быть какими угодно. Символ возврата каретки ни на что не влияет.
У меня на клиенте не влияет, а у пинга (вроде) на ноде с ними были проблемы.
Но вообще если уж под старину подстраиваться (семибитные каналы и всё такое), то у всех подобных протоколов де-факто стандартом является CRLF.
AL> Ну новый стандарт будет компактный и простой.
Это хорошо. Ждём-с.
AL> Жди и всё будет. У меня сейчас не очень простой период в жизни в плане свободного времени.
Понимаю, сам вот только недавно из отпуска вышел.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 20:33
Andrew Lobanov (tavern,1) => hClhhwxDO416SUNu3b9A
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> Мне кажется ты совсем не читаешь то, что я тебе пишу. Прекращаю это бессмысленное занятие. :)
revoltech>> Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.
hugeping> На самом деле с переводами тоже не все просто. Я когда написал фильтр получил ещё несколько сообщений с \r где-то в теле. Я стал их резать при записи в БД. Кстати, ещё один источник того, что хеш может отличаться. В общем, idec и ii не требуют совпадений при пересчёте хеша. Пересчёт вообще не должен нигде проводиться.
Вообще, надо забыть что это хеш по своему происхождению и постараться вспомнить, что это msgid. Единственная его роль, единственное назначение.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
27.10.2024 21:42
doesnm (ping,55) => 1euPz0nKQrrAznEZOjCG
shaos>> дык у него ещё нету ноды - тока клиент :)
AL> Вот и повод написать ноду :)
Может и мне что нибудь написать. Хотя это скорее всего будет очередной проект в /projects который я подзаброшу из-за лени или какого-то затыка и когда-то давно вернусь
+++ Никто не знает, как правильно. Так зачем же выдумывать правила?
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 08:34
Andrew Lobanov (tavern,1) => NyN2c2RQwFyEPjgOQJHj
AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.
hugeping> А ты знаешь, подумал... Вообще, мне нравится. Без x/c можно жить, тем более если list.txt в базе будет.
В list.txt счётчик может убывать.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 11:54
Andrew Lobanov (tavern,1) => 1t0CZs5lzqVxsohtOvjd
Накинул приблизительный черновик стандарта.
http://s.spline-online.ru/idec.html
Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 12:30
revoltech (spnet, 4) => KFDLKshz4EiKcBfNXl6P
AL> Накинул приблизительный черновик стандарта.
AL>
AL> http://s.spline-online.ru/idec.html
AL>
AL> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
Выглядит неплохо. Но несколько моментов:
1) было бы неплохо уточнить символ переноса строки;
2) было бы неплохо уточнить для непосвящённых, что такое аплинки и даунлинки;
3) в старом стандарте указано, что для постинга именно через GET /u/point поле tmsg должно быть закодировано не просто в Base64, а в Base64-urlsafe. В новом стандарте это требование убирается или как?
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 12:35
revoltech (spnet, 4) => BGZgkMOP4Ruv4vRpIX7J
doesnm> Отличия от ii только в имени эх?
И в слайсах.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 12:27
doesnm (ping,55) => KFDLKshz4EiKcBfNXl6P
AL> Накинул приблизительный черновик стандарта.
AL> http://s.spline-online.ru/idec.html
AL> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
Отличия от ii только в имени эх? Просто на глаз по памяти ничего другого не заметил
+++ Никто не знает, как правильно. Так зачем же выдумывать правила?
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 12:54
Andrew Lobanov (tavern,1) => BGZgkMOP4Ruv4vRpIX7J
AL>> Накинул приблизительный черновик стандарта.
AL>> http://s.spline-online.ru/idec.html
AL>> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
doesnm> Отличия от ii только в имени эх? Просто на глаз по памяти ничего другого не заметил
Имена эх ничем не отличаются от ii-шных. Там ничем они не ограничивались фактически. Так что только слайсами отличается. Остальное шелуха :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 13:18
Andrew Lobanov (tavern,1) => nHIwTqSHAQV5m9zr0XOv
AL>> Накинул приблизительный черновик стандарта.
AL>>
AL>> http://s.spline-online.ru/idec.html
AL>>
AL>> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
revoltech> Выглядит неплохо. Но несколько моментов:
revoltech> 1) было бы неплохо уточнить символ переноса строки;
Всё ещё не считаю это задачей стандарта. Мы передаём текст. Любой. Хотя, если большинство согласится, что нам нужно это стандартизировать, соглашусь.
revoltech> 2) было бы неплохо уточнить для непосвящённых, что такое аплинки и даунлинки;
Я думаю, что надо сделать словарик. Но не хочу пихать его непосредственно в стандарт.
revoltech> 3) в старом стандарте указано, что для постинга именно через GET /u/point поле tmsg должно быть закодировано не просто в Base64, а в Base64-urlsafe. В новом стандарте это требование убирается или как?
Безоговорочно принимается. Требование остаётся.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 13:49
doesnm (ping,55) => lrwddqyvYqZf8sCIz3gq
doesnm>> Отличия от ii только в имени эх?
revoltech> И в слайсах.
Может я слепой, но по ссылке не нашел упоминания слайсов
+++ Никто не знает, как правильно. Так зачем же выдумывать правила?
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 14:31
Andrew Lobanov (tavern,1) => I3l85uQeZ4Flf61agjdt
doesnm>>> Отличия от ii только в имени эх?
revoltech>> И в слайсах.
doesnm> Может я слепой, но по ссылке не нашел упоминания слайсов
2.3 /u/e/
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 18:30
revoltech (spnet, 4) => yRy4KMZnadgQYEXLbtGF
AL> Всё ещё не считаю это задачей стандарта. Мы передаём текст. Любой. Хотя, если большинство согласится, что нам нужно это стандартизировать, соглашусь.
А как же интероперабельность? Вот, допустим, человек решил написать клиента под старый Макинтош. Очень старый, ещё на процессоре архитектуры 68k, где ещё MacTCP отдельным пакетом шёл. Знаешь, какой на тех макосях тогда был стандартный символ перевода строки? Не LF и даже не CRLF, а именно CR. И как, будет тот клиент работать с существующими нодами, если стандарт не уточнит этот момент?
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 19:30
Andrew Lobanov (tavern,1) => 1nCiwup6XJSmxXtb94YB
AL>> Всё ещё не считаю это задачей стандарта. Мы передаём текст. Любой. Хотя, если большинство согласится, что нам нужно это стандартизировать, соглашусь.
revoltech> А как же интероперабельность? Вот, допустим, человек решил написать клиента под старый Макинтош. Очень старый, ещё на процессоре архитектуры 68k, где ещё MacTCP отдельным пакетом шёл. Знаешь, какой на тех макосях тогда был стандартный символ перевода строки? Не LF и даже не CRLF, а именно CR. И как, будет тот клиент работать с существующими нодами, если стандарт не уточнит этот момент?
Принимается. Укажу конкретный символ тогда.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 20:04
shaos (spnet, 2) => 1nCiwup6XJSmxXtb94YB
Ну можно написать, что принимаем любой текст, но сохраняем только с \n (и сервер считает хеш уже по сконверченному тексту)
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 20:10
revoltech (spnet, 4) => eBDAIZ4MQkEk0NyLzFH6
shaos> Ну можно написать, что принимаем любой текст, но сохраняем только с \n (и сервер считает хеш уже по сконверченному тексту)
Это усложнит логику сервера и, что важнее, замедлит обработку постов.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 20:17
Andrew Lobanov (tavern,1) => KFDLKshz4EiKcBfNXl6P
Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
Словарик будет отдельным документом.
Какие-либо ещё замечания и предложения будут?
PS: Перед окончательной публикацией дождусь реакции hugeping.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 20:27
shaos (spnet, 2) => qaKfdAStgdwxZtmEHmkJ
Что значит усложнит? Валидацию входящего в любом случае надо делать - вот вместе с валидацией и делать конверсию если надо
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 20:31
revoltech (spnet, 4) => AApgmhTTZZc1yhkKlf59
shaos> Что значит усложнит? Валидацию входящего в любом случае надо делать - вот вместе с валидацией и делать конверсию если надо
Ну то и значит, что валидация требует одни ресурсы, а конверсия — уже другие. Вот как раз нужно или не нужно делать конверсию — это уже дело конкретной станции. Например, с \r\n можно обрезать \r, а только с \r уже не принимать.
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 21:29
shaos (spnet, 2) => OA385fr1uIVrogLm5diO
Это всё делается в одной функции
--------------------------------------------------------------------------------
subject: Re: Стандарт
28.10.2024 22:18
shaos (spnet, 2) => SNhm1xSAyqdnvSh897zA
А где /x/features ?
Может их в виде /features.txt организовать? Всё равно это по сути статический текст…
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 00:27
revoltech (spnet, 4) => buzTTOVY6bY1bRUDBZBg
shaos> А где /x/features ?
Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 00:44
ahamai (blackcat, 2) => vw94xxAktnhjmcpvvp7F
> Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.
проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает. если бы это был запрос /u/e/ea/ea/ea?s=-100:100, тогда бы посторонние ноды это проигнорировали
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 00:46
ahamai (blackcat, 2) => hua5b4LxCs1t9kF9HsTs
http://ii.blcat.ru/u/e/idec.talks/-100:100
====
idec.talks
nQi82oyWBVG04BKEAssb
[... cut ...]
vw94xxAktnhjmcpvvp7F
hua5b4LxCs1t9kF9HsTs
-100:100
====
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 01:27
shaos (spnet, 2) => hua5b4LxCs1t9kF9HsTs
Там же точки нету - там двоеточие
Значит проверку на соответствие имени эхи оно пройти не должно ;)
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 01:27
revoltech (spnet, 4) => hua5b4LxCs1t9kF9HsTs
ahamai> проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает.
Это в каких таких эхах есть двоеточия в названии?
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 01:29
revoltech (spnet, 4) => wABF0QTI35UvdhiQJAia
shaos> Там же точки нету - там двоеточие
shaos> Значит проверку на соответствие имени эхи оно пройти не должно ;)
Вот именно. Тоже хотел добавить.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 01:31
shaos (spnet, 2) => 0PBT2nv9kzNhXf9F32CF
Наверное старая нода должна ошибку вернуть если в запросе непонятное буквосочетание попалось, не?
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 02:11
ahamai (blackcat, 2) => AFoiXEz42KsbltnXRlkc
Речь о том, как на это реагирует референсная реализация. Хреново :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 03:48
shaos (spnet, 2) => 5Idee6yM9U6RT8Ambvyl
А поправить референсную реализацию? ;)
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 04:07
ahamai (blackcat, 2) => vwr3YMx2Lzz3cdzxhj3L
ну, во-первых, это единственные существующие реализации в сети, хранятся на github, моя нигде кроме этого сайта не хранится и начинать, наверное, надо, именно с них. не знаю, что будут делать клиенты с эхой -100:100 :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 06:02
shaos (spnet, 2) => fi01Bk3rTIBXMyA270LA
А существующие реализации в сети не 100% IDEC уже? ;)
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 06:26
ahamai (blackcat, 2) => 3zoUGp7x6tCSLedUsgUW
Ну я показал как моя станция на это реагирует
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 07:00
Andrew Lobanov (tavern,1) => buzTTOVY6bY1bRUDBZBg
shaos> А где /x/features ?
А зачем она, если не будет расширений? Расширения были ошибкой.
shaos> Может их в виде /features.txt организовать? Всё равно это по сути статический текст…
Можно что угодно вертеть, но в стандарте этому не место.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 07:00
Andrew Lobanov (tavern,1) => hua5b4LxCs1t9kF9HsTs
>> Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.
ahamai> проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает. если бы это был запрос /u/e/ea/ea/ea?s=-100:100, тогда бы посторонние ноды это проигнорировали
В тмени эхи не может быть двоеточия. Так что не выглядит. Ну и просто будет пустой индекс невалидной эхи в ответе. Это ничему не навредит.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 07:00
Andrew Lobanov (tavern,1) => UFyt2pK0PcvYpB6RTdpd
shaos> Наверное старая нода должна ошибку вернуть если в запросе непонятное буквосочетание попалось, не?
Надо на таверне проверить. Старше сейчас, вроде, ничего нет.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 07:00
Andrew Lobanov (tavern,1) => 5Idee6yM9U6RT8Ambvyl
ahamai> Речь о том, как на это реагирует референсная реализация. Хреново :)
А у нас пока нет референсной реализации. Стало быть никак не отреагирует.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 07:00
Andrew Lobanov (tavern,1) => 3zoUGp7x6tCSLedUsgUW
shaos> А существующие реализации в сети не 100% IDEC уже? ;)
У Ромы никогда не было IDEC-ноды. Блин. Научить фетчер работать без слайсов с некоторыми аплинками - задача на 2-3 лишние строки кода. Проблема высосана из пальца.
Если бы IDEC был ii, то он бы назывался ii.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 07:02
Andrew Lobanov (tavern,1) => N1GR0yaXbIQO6DarSpba
ahamai> Ну я показал как моя станция на это реагирует
Реакция твоего узла странная, но ни к каким последствиям не приводит.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 08:25
shaos (spnet, 2) => 4o2eUQWM87XWu9PY2Mj7
это как так? перечисляемые расширения были основной фишкой IDEC :(
вот например мой /x/features прямо сейчас:
u/e
u/push
list.txt
list.txt?h=1
listhsh.txt
blacklist.txt
x/c
x/h
x/file
x/filelist
node.json
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 08:28
shaos (spnet, 2) => 2AEIbIPAy21q5GhoCK4R
Ну у него эхи без цифр, значит уже наполовину IDEC ;)
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 08:33
tuple (ping,54) => SNhm1xSAyqdnvSh897zA
AL> Словарик будет отдельным документом.
Лучше в самом документе словарик иметь.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 09:10
revoltech (spnet, 4) => E3hUjdux6AjtnMg8KsDE
shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(
Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 09:12
revoltech (spnet, 4) => 266SvQOH48eec09O6yBN
revoltech> три из них являются частью стандарта
Пардон, /u/push не увидел. В таком варианте — даже четыре.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 09:37
shaos (spnet, 2) => AAOwTvPc4ywKd6TA6xN9
А как же делать кастомные расширения теперь?...
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 09:46
Andrew Lobanov (tavern,1) => E3hUjdux6AjtnMg8KsDE
shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(
Перечисляемые расширения вынуждают стандартизировать расширения. Придём к джабберу, где у каждого свой зоопарк и по факту в рамках сети рабоает только основа стандарта и пара расширений. Нафиг-нафиг.
А так, никто не мешает лепить любые расширения у себя. Просто не надо полагаться на то, что их будут поддерживать. Ситуация ровно та же, только более свободная.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 09:46
Andrew Lobanov (tavern,1) => 8PENsljzly0kcD17Co18
shaos> Ну у него эхи без цифр, значит уже наполовину IDEC ;)
Да не было в ii требования эх с циферками. Это была просто договорённость, а не стандарт. Эхи без циферек там прекрасно работали всю дорогу.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 09:54
shaos (spnet, 2) => XZKvlrzWZ4qb2UlrkO8m
Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 09:53
Andrew Lobanov (tavern,1) => Mm6rcZYpzhcMu2n1T80T
AL>> Словарик будет отдельным документом.
tuple> Лучше в самом документе словарик иметь.
Словарик не является частью стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 09:53
Andrew Lobanov (tavern,1) => 266SvQOH48eec09O6yBN
shaos>> это как так? перечисляемые расширения были основной фишкой IDEC :(
revoltech> Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.
Всё так. Расширения стандарта это путь вникуда. Лучше потихоньку принимать в стандарт полезняшки, если они будут действительно нужны.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 10:06
shaos (spnet, 2) => qaM0nAnX0aVBnmEQDdD5
https://github.com/idec-net/new-docs/blob/master/iibonds.md
Минусы оригинального ii:
- Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
- Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
- Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую
Наши улучшения
- Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
- Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
ВСЁ!
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 10:43
Andrew Lobanov (tavern,1) => Fk5TKs4AVdIj8K3iNQu7
shaos> А как же делать кастомные расширения теперь?...
Я ж говорю, важна поддержка стандарта. Что там кто себе сбоку наворотил, это их личное дело и не должно влиять на всю сеть.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 10:43
Andrew Lobanov (tavern,1) => lyhVniClqwe3mzSbqLJr
shaos> Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...
Почему? Хочешь сказать, что со старым стандартом исключалась сама возможность получить у тебя /list.txt с хешиками?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 10:43
Andrew Lobanov (tavern,1) => 5AAPMNDStz5YjUzom6oR
shaos> https://github.com/idec-net/new-docs/blob/master/iibonds.md
shaos> Минусы оригинального ii:
shaos> - Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
shaos> - Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
shaos> - Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую
Имеет смысл читать ii, а не кривую документацию по IDEC.
shaos> Наши улучшения
shaos> - Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
shaos> - Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
shaos> ВСЁ!
Да.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 11:34
tuple (ping,54) => Wbu56brwPq0I0UnPAR7p
AL> Имеет смысл читать ii, а не кривую документацию по IDEC.
Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 13:14
Andrew Lobanov (tavern,1) => nYd9p4GuWxHj12aRNJA8
AL>> Имеет смысл читать ii, а не кривую документацию по IDEC.
tuple> Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.
Не знаю. Мы уже давно отдельно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 17:12
shaos (spnet, 2) => nWfBZQwo0CRQWJyNO86w
Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 17:14
shaos (spnet, 2) => Wbu56brwPq0I0UnPAR7p
> Да.
Ну дык значит bloat уже на половину IDEC :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 17:28
shaos (spnet, 2) => ErpxfyUY2zR2xvv2Ur1v
blcat
чортова автоисправлялка…
--------------------------------------------------------------------------------
subject: Re: Стандарт
29.10.2024 20:58
Andrew Lobanov (tavern,1) => fWNOAltbi4QKLAWXOtLC
shaos> Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)
Ну так и оставь их в /x/features. Никто ж не мешает ;)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
30.10.2024 11:01
hugeping (ping,1) => SNhm1xSAyqdnvSh897zA
AL> Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
AL> PS: Перед окончательной публикацией дождусь реакции hugeping.
Вроде бы всё нормально! У меня был вопрос про push как часть стандарта. Он нужен только когда нода не имеет реального IP адреса? С другой стороны, как тогда поинта забирают с неё сообщения? Какой-то изолированный сегмент сети?
С другой стороны, всё равно эта часть возможна только за счёт предварительной договорённости нод (выдача пароля), так что думаю - наличие push в стандарте не приговор, а лишь означает, что ПРИ НЕОБХОДИМОСТИ этот механизм может использоваться. То-есть, для работы в обычном режиме нам по прежнему push не нужен...
Про фичи - по идее они полезны были бы для определения, например, поддерживает ли нода слайсы. Но на практике, tgistation их не поддерживает, но в фичах есть u/e. В общем, я не жалею, что их больше нет. Стало проще. Меньше комбинаций. Ориентироваться можно на фактически получаемые данные.
P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)
--------------------------------------------------------------------------------
subject: Re: Стандарт
30.10.2024 12:27
tuple (ping,54) => SSN8S13JHpJBu1zlOvmU
hugeping> P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)
Солидарен. Оставить повисеть на неделю-две.
--------------------------------------------------------------------------------
subject: Re: Стандарт
30.10.2024 12:28
Andrew Lobanov (tavern,1) => SSN8S13JHpJBu1zlOvmU
AL>> Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
AL>> PS: Перед окончательной публикацией дождусь реакции hugeping.
hugeping> Вроде бы всё нормально! У меня был вопрос про push как часть стандарта. Он нужен только когда нода не имеет реального IP адреса? С другой стороны, как тогда поинта забирают с неё сообщения? Какой-то изолированный сегмент сети?
Ну по сути да. Если вдруг есть узел в сети с ограниченным доступом в интернет, например. Поинты у него локальные, а наружу только пуши до аплинка. Ситуация гипотетическая и с каждым годом всё менее вероятная, хотя, с другой стороны, с этими всеми взаимными блокировками может оказаться всякое :)
hugeping> С другой стороны, всё равно эта часть возможна только за счёт предварительной договорённости нод (выдача пароля), так что думаю - наличие push в стандарте не приговор, а лишь означает, что ПРИ НЕОБХОДИМОСТИ этот механизм может использоваться. То-есть, для работы в обычном режиме нам по прежнему push не нужен...
Ну да. В обычном режиме push не нужен.
hugeping> Про фичи - по идее они полезны были бы для определения, например, поддерживает ли нода слайсы. Но на практике, tgistation их не поддерживает, но в фичах есть u/e. В общем, я не жалею, что их больше нет. Стало проще. Меньше комбинаций. Ориентироваться можно на фактически получаемые данные.
Ну вот не будет фич. Будет просто стандарт. Остальное вообще не важно вне рамок каких-то локальных приколов.
hugeping> P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)
Ну спешить некуда.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
02.11.2024 09:03
Andrew Lobanov (tavern,1) => SNhm1xSAyqdnvSh897zA
Очередные правки. URL тот же: http://s.spline-online.ru/idec.html
Добавил явное указание запросов бандлов по 40 сообщений. Прояснил про строку аутентификации для пушей.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Стандарт
03.11.2024 05:25
shaos (spnet, 2) => pKGfeaWwvIFEsQKxuAxN
Заметил лишний пробел:
> Количество сообщений указывается от 0 до произвольного числа. Если количество равно нулю, индекс строится от смещения до конца. Если сумма смещения и количества превышает фактическу ю длину индекса на узле, отдаются все msgid от смещения до конца индекса.
фактическу_ю
--------------------------------------------------------------------------------
subject: Re: Стандарт
03.11.2024 05:36
shaos (spnet, 2) => vhmkPIkTPRZOJkyFiwFS
> Узел должен обеспечивать запрос 40 сообщений в одном запросе /u/m. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.
Может быть первое предложение подкорректировать?
Количество одновременно запрашиваемых сообщений в одном запросе /u/m не должно превышать 40. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.
--------------------------------------------------------------------------------