разговоры про технологию nn/ii, idec






\/ . shaos to ahamai @ Re: Разбор idec 31/10/24 03:17

Не надо драматизировать :)

Индексы тоже пару строк кода добавляют (ну может чуть больше)

Для разнообразия можно множественные "слайсы" тоже сделать, типа

/u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4

будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

3PasI6... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: тестовый архив 31/10/24 03:22

Интересно, что ii.stat я взял с таверны, и сам добавляю туда еженедельную статистику, а там остался старый вариант остановившийся в 2018 году :)

Люди, дайте ii.14 у кого есть? Очень хочется в промежуточную историю окунутся между тем что было на alicorn и тем что сейчас - я письмо ake написал (у него на станции было), но он не отвечает...

0znI8z... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Разбор idec 31/10/24 03:30

кто будет переписывать цезий или фетчеры под замену стандартов? стандарты уже такие, какие получились. у меня вопрос - чому так?

> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

если менять это, то надо убирать неэхи из стрки для эх. чтобы оно прозрачно накладывалось, а не как у меня пишет -100:100 в файле списка, потому что на это вообще не рассчитвалась. в /u/e должны быть только эхи, это изначальный стандарт

h7Htet... . ОТВЕТИТЬ



\/ . shaos to shaos @ Re: тестовый архив 31/10/24 03:39

Ещё момент - lor-opennet.17 есть в таверне тоже, только она там глючит (сразу после сбойного сообщение оно размножается)

7n8wAA... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Разбор idec 31/10/24 03:42

> кто будет переписывать цезий или фетчеры под замену стандартов?

никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!

tKKWPp... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Разбор idec 31/10/24 03:46

> если менять это, то надо убирать неэхи из стрки для эх

очевидно, что запись [-]N:M не является эхой т.к. там не точка, а двоеточие (и может быть минус вначале)

Ljzxyj... . ОТВЕТИТЬ



\/ . shaos to shaos @ Re: Разбор idec 31/10/24 04:20

> Индексы тоже пару строк кода добавляют (ну может чуть больше)

Ну ок не 2 строки, а 20, но тем не менее :)

====
elseif ($opts[0] == 'u' and $opts[1] == 'e') {
        $work_options=array_slice($opts, 2);
        $w_opts_count=count($work_options);

        if (
                $w_opts_count > 1 and
                strstr($work_options[$w_opts_count-1], ":")!==false
        ) {
                $buffer="";
                $numbers=explode(":", $work_options[$w_opts_count-1]);

                $a=intval($numbers[0]);
                $b=intval($numbers[1]);

                $echoareas=array_slice($work_options, 0, $w_opts_count-1);
                $messages=[];

                foreach ($echoareas as $echo) {
                        $slice = $access->getMsgList($echo, $a, $b);

                        if (count($slice) > 0) {
                                $buffer.=$echo."\n".implode("\n", $slice)."\n";
                        } else {
                                $buffer.=$echo."\n";
                        }
                }
                echo $buffer;

        } else {
                foreach($work_options as $echo) {
                        echo $echo."\n".implode("\n", $access->getMsgList($echo))."\n";
                }
        }
}
====



Это так в ii-php и я думаю не сильно сложнее будет поддержать "слайсы" в любом месте строки, а не только в конце...

NfQ2OP... . ОТВЕТИТЬ





\/ . ahamai to shaos @ Re: Разбор idec 31/10/24 04:10

Это надо дополнительно разбирать. Когда иожно было бы этого не делать. Это неочевидно, теряется простота. И это порождает артефакты там, где это не поддерживается. Я всё написал выше, это ненужная работа вследствие плохого дизайна. Не надо пихать что то в список эх, это кривит архитектуру.

THxYbR... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Разбор idec 31/10/24 04:28

Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?

GKhAkw... . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: Разбор idec 31/10/24 05:00

ahamai> Складывается впечатление, что idec это пример плохого проектирования.

На это я пытался намекнуть чуть ли не с первого дня появления здесь.

ahamai> MSGID? по логике вроде бы да.

Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.

Но в целом согласен, текущий формат слайсов какой-то недоработанный. Не то чтобы его сложно реализовать, но задачи экономить трафик при запросе большого количества эх он действительно не решает.

Я ещё могу понять, почему всё через / — это проще парсить, чем отдельно компоненты пути и компоненты HTTP query, особенно учитывая, что от HTTP в общем случае можно (и нужно) отходить. Но я не могу понять, почему бы не сделать в запросе такую же железобетонную структуру ключ-значение, как и в тегах бандла ii/ok/repto/blabla:

/u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10

Этот формат (после удаления первого слэша) однозначно парсится в ключ-значение, на тикле он вообще одним сплитом преобразуется в список, читающийся через dict. И тогда и дополнительных проверок на то, где название эхи, а где диапазон, делать не нужно. Первый ключ — u со значением e, второй ключ — echo.1 со значением all и так далее. А сейчас всё как-то дико контекстозависимо получается, потенциал допустить ошибку куда выше.

El8TC5... . ОТВЕТИТЬ







\/ . revoltech to revoltech @ Re: Разбор idec 31/10/24 05:03

revoltech> /u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10

И да, в моём варианте вместо диапазона легко подставить msgid, и так же легко на стороне сервера проверить, что именно там стоит. Если диапазон, берём диапазон, если msgid, берём от этого msgid.

0ozmZV... . ОТВЕТИТЬ



\/ . revoltech to revoltech @ Дополнения к стандарту 31/10/24 05:14

Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):

/u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10

А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.

KmXTgt... . цепочка . ОТВЕТИТЬ



\/ . revoltech to Andrew Lobanov @ Re: Разбор idec 31/10/24 05:31

AL> И это ломает поддержку стандарта.

Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?

revoltech> А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.

Сейчас у меня в фетчере это значение по умолчанию равно 12, пока явно не указано обратное. Было бы неплохо, если бы станция сообщала эту информацию клиенту для оптимального выкачивания мессаг.

E5UxKD... . ОТВЕТИТЬ





\/ . Andrew Lobanov to ahamai @ Re: Срез 31/10/24 05:21

ahamai> Хэш в блеклисте это вообще ничего не меняет, нужны же "сообщения от", если в файле эхи сообщение есть, то от него и пойдёт. Если хэша нет, то отдастся вся эха. По сравнению с текущим случаем, преимуществ два - хэш гораздо более надёжный источник, чем количество сообщений, и не сработает только в одном случае: если конкретная нода инъектировала в эху сообщения сверху - но на это нужно иметь настолько серьёзные основания, что это повод говорить об этом в сисопской эхе.

Какие-то количества сообщений придумал. Нет их уже, считай. Легаси, который в скором времени выставим на мороз.

> Ну и второе - точно отдадутся только самые новые сообщения, одним запросом (я думал, реализация срезов вообще не так работает, в текущем виде она вообще какая-то непонятная, почему на все эхи один лимит, если сообщений в базе мало)

Как количество сообщений влияет на работу срезов? Out of range невозможен.

ahamai> не использовалось это никогда потому что я не вижу смысла экономить и так копеечный трафик. но на такой случай реализация в моей станции была

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

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

ynT4Ap... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Срез 31/10/24 05:21

ahamai> Понятия не имею, что это слово означает, но вопросы имеются - раньше я вообще никогда не задумывался, как работают слайсы.
ahamai> Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи.

Читай документацию внимательнее. Там не только эхи перечисляются.

ahamai> Почему не использовать что-то типа ?s=-100:100 или любой другой способ?

Мы и используем один из любых других способов.

ahamai> Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения.

Почему у тебя фетчер считает имя эхи хэшем сообщения? Это явно что-то не так в ii 0.3. Зачем с аплинком на ii использовать то, что ii не умеет?

ahamai> Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?

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

ahamai> Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез.

Зачем?

ahamai> Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных?

1. Ты тоже в максималисты подался? Затем, что лишних несколько сотен байт на фоне нескольких сотен килобайт это экономия трафика.

2. Ненужные сообщения не тянутся. Только новые. u/e, если ты забыл, даёт только индекс, но не сообщения.

ahamai> А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться

И этот человек защищал кучу маленьких бандлов вместо всего в одном запросе.

ahamai> Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно.

Однопоточный фетчер на срезах на перле, который тянет индекс по одной эхе и использует бандлы по 40 сообщений, утягивает клуб за 3 минуты. На медленном канале.

Он же, но с парой десятков сообщений новых сообщений работает 3-5 секунд.

Без новых сообщений он отрабатывает за 3-4 секунды.

ВНИМАНИЕ! Вопрос: куда ты так спешишь, что у тебя каждая секунда на счету?

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

zKWkyT... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: игры в эхах 31/10/24 05:21

>> Можно передавать уровни сокобана в plaintext-формате (.sok).
ahamai> это всё не так весело, тут играешь в одиночку. а я именно про игры всей компанией и совместную вовлечённость

Многие НРИ годятся для такого занятия. Всей гурьбой, увлекательно, разнообразно.

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

r4pg6a... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Срез 31/10/24 05:21

ahamai> - если сообщений в базе мало
ahamai> + если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
ahamai> 111
ahamai> Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.

Оверхед меньше килобайта в подавляющем большинстве случаев. Это даже на 9600 бод можно не считать оверхедом. При этом ты предлагаешь более сложный и неработающий в части случаев вариант.

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

BYbr0F... . ОТВЕТИТЬ



\/ . Andrew Lobanov to tuple @ Re: игры в эхах 31/10/24 05:21

tuple> Ещё есть вариант найти мастера, сыграть в D&D.

В общем случае неудобно. Карту надо и токены.

tuple> P.S. Чур я бард-человек.

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

tIMjF4... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Разбор idec 31/10/24 05:21

Я честно пытался с тобой обсуждать, но ты, похоже, наркоман. Ты видишь то, чего нет.

За сим считаю, что обсуждение стандарта с тобой можно завершать. Какие счётчики? Какое скачивание лишних сообщений? Если ты не читал то, что я сюда приносил как черновик, то открой хотя бы исходники своего ii-0.3. Почитай на досуге. Сразу увидишь где ты неправ в своих претензиях. Ну а если не увидишь, то обсуждать с тобой дизайн, стандарт и реализацию тем более нет смысла.

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

28eoI3... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: тестовый архив 31/10/24 05:21

ahamai> смотрю я на это и думаю, а давайте ru.humor.14 на бон вернём?

У нас нет бона.

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

BBQjjL... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 05:21

shaos> Не надо драматизировать :)
shaos> Индексы тоже пару строк кода добавляют (ну может чуть больше)
shaos> Для разнообразия можно множественные "слайсы" тоже сделать, типа
shaos> /u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4
shaos> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

И это ломает поддержку стандарта.

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

clkDeN... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Разбор idec 31/10/24 05:21

ahamai> кто будет переписывать цезий или фетчеры под замену стандартов? стандарты уже такие, какие получились. у меня вопрос - чому так?

Из стандарта выкидывается то, что по факту никому не нужно. Стандарты полностью совместимы с ii. Так что не понимаю твоего бухчения. Ты можешь взять хоть свой горячо любимый ii-0.3 и работать в сети полноценно.

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

oVVZVJ... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 05:21

>> кто будет переписывать цезий или фетчеры под замену стандартов?
shaos> никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!

Ну просто всё несовместимое снимается с фетча. Зачем нам поломанные узлы?

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

bPA84F... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 05:21

shaos> Блин как эти ==== в этом ii-php работают?

Это знает только автор. И то вряд ли вспомнит.

shaos> Ненавижу регулярные выражения...

Что может быть проще? Грамматики? Конечные автоматы?

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

o49x4s... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Разбор idec 31/10/24 05:36

ahamai> Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?

Проблему длинных индексов. Всё максимально прозрачно и понятно. Использование разных по смыслу значений в роутерах это нормальная практика. Посмотри хоть на ii. У тебя /u/e -- часть пути, которая определяет функционал. А параметры у неё что? Тоже часть пути. Зачем ты сделал эту неоднозначность?

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

XGlzrR... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Разбор idec 31/10/24 05:36

ahamai>> Складывается впечатление, что idec это пример плохого проектирования.
revoltech> На это я пытался намекнуть чуть ли не с первого дня появления здесь.

Но ты всё ещё здесь. В интернете кто-т неправ? Или что?

ahamai>> MSGID? по логике вроде бы да.
revoltech> Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.

ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.

revoltech> Но в целом согласен, текущий формат слайсов какой-то недоработанный. Не то чтобы его сложно реализовать, но задачи экономить трафик при запросе большого количества эх он действительно не решает.

Ну да. Вместо выкачивания сотен килобайт мы выкачиваем сотни байт. Никакой экономии!

В общем, обсуждение не имеет смысла. По делу все высказались, рассуждения не по делу не имеют смысла.

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

01EQ9U... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Разбор idec 31/10/24 05:40

ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)

OWSdy5... . ОТВЕТИТЬ





\/ . shaos to Andrew Lobanov @ Re: Разбор idec 31/10/24 05:42

> Это знает только автор. И то вряд ли вспомнит.

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

====
        for ($i = 0; $i < count ($string); ++$i) {
                $string[$i] = preg_replace("/([^\w\/])(www\.[a-z0-9\-]+\.[a-z0-9\-]+)/i", "$1http://$2",$string[$i]);
                $string[$i] = preg_replace("/([\w]+:\/\/[\w\-?&;%#~=\.\/\@]+[\w\/])/i","<a target=\"_blank\" href=\"$1\">$1</a>",$string[$i]);
                $string[$i] = preg_replace("/([\w\-?&;#~=\.\/]+\@(\[?)[a-zA-Z0-9\-\.]+\.([a-zA-Z]{2,3}|[0-9]{1,3})(\]?))/i","<a href=\"mailto:$1\">$1</a>",$string[$i]);
                $echo_check = preg_replace("/(.*)\<a target=\"_blank\" href=\"ii:\/\/(.+?)\"\>(.+?)\<\/a\>(.*)/", "$2", $string[$i]);
                if ($access->checkEcho($echo_check)) {
                        $string[$i] = preg_replace("/target=\"_blank\" href=\"ii:\/\/(.+?)\"/s", "class=\"iilink\" href=\"?echo=$1\"", $string[$i]);
                } else {
                        $string[$i] = preg_replace("/target=\"_blank\" href=\"ii:\/\/(.+?)\"/s", "class=\"iilink\" href=\"?msgid=$1\"", $string[$i]);
                }
                if (preg_match("/^====$/", $string[$i])) {
                        if (!$pre_flag) {
                                $pre_flag = true;
                                $string[$i] = preg_replace("/====/", "<pre>====", $string[$i]);
                        } else {
                                $pre_flag = false;
                                $string[$i] = preg_replace("/====/", "====</pre>", $string[$i]);
                        }
                }
                if(!$pre_flag && preg_match("/^\s?[a-zA-Zа-яА-Я0-9_\-]{0,20}(&gt;)+.+$/i", $string[$i])) {
                        $string[$i]="<span class='quote'>".$string[$i]."</span>";
                }

                if(!$pre_flag) {
                        $string[$i]=preg_replace("/(^|\s+)(PS|P\.S|ЗЫ|З\.Ы|\/\/|#).+$/i", "<span class='comment'>\\0</span>", $string[$i]);
                }
        }
        if ($pre_flag) $string[count($string) - 1] .= "</pre>";
====


4T2pxE... . ОТВЕТИТЬ





\/ . revoltech to shaos @ Re: Дополнения к стандарту 31/10/24 05:48

shaos> ну разве что если /x/e/...

Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.

EeLfzf... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Разбор idec 31/10/24 05:53

> Что может быть проще? Грамматики? Конечные автоматы?

Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...

INoKik... . ОТВЕТИТЬ





\/ . ahamai to shaos @ Re: Разбор idec 31/10/24 05:43

Кстати, если в срезе будет точка, то старый софт будет считать это не как неккорректный msgid, а как пустую эху и и игнорировать её

XBpkmZ... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Дополнения к стандарту 31/10/24 06:05

shaos> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать

Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.

QRaXIY... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Дополнения к стандарту 31/10/24 06:12

> Но её админ должен об этом знать.

Ну я например не знал пока не загуглил :)

Потом пришлось свой анализатор логов переписывать, чтобы строки длинне 8К принимал ;)

Lvy7a9... . ОТВЕТИТЬ



\/ . ahamai to Andrew Lobanov @ Re: Разбор idec 31/10/24 07:03

> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.

В бандле только эхи и msgid. Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируй

9WpkPy... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Разбор idec 31/10/24 07:52

AL>> И это ломает поддержку стандарта.
revoltech> Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?

Ненужная вещь.

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

6XtvzA... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 07:52

>> Это знает только автор. И то вряд ли вспомнит.

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

====
                if (preg_match("/^====$/", $string[$i])) {
                        if (!$pre_flag) {
                                $pre_flag = true;
                                $string[$i] = preg_replace("/====/", "<pre>====", $string[$i]);
                        } else {
                                $pre_flag = false;
                                $string[$i] = preg_replace("/====/", "====</pre>", $string[$i]);
                        }
                }
====



А что тут разбираться? Может, кто-то пихает пробелы после ====? Ну так надо просто им напихать в панамку за это.

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

hD58ue... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 07:52

>> Что может быть проще? Грамматики? Конечные автоматы?
shaos> Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...

Как только начинаем писать что-то сложнее поиска подстроки, код на Си превращается в чан доширака. Регулярки надо осилить один раз и потом кратко и лаконично описывать желаемое.

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

nW1CqA... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 07:52

revoltech> Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
revoltech> /u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10

Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.

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

NkzCRB... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 07:52

shaos> ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)

Тем, что не решает никаких проблем :)

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

TM4jqb... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 07:52

shaos>> ну разве что если /x/e/...
revoltech> Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.

Не вижу в нём смысла.

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

Fz6ja0... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Разбор idec 31/10/24 07:52

ahamai> Кстати, если в срезе будет точка, то старый софт будет считать это не как неккорректный msgid, а как пустую эху и и игнорировать её

Ты хочешь в срезе получить нецелое количество сообщений? Зачем тебе точка в срезе? Типа, -12.5:12.5?

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

uHrVWV... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 07:52

shaos>> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
revoltech> Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.

А зачем?

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

53JOed... . ОТВЕТИТЬ



\/ . hugeping to revoltech @ Re: Дополнения к стандарту 31/10/24 07:40

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

Понимаю, что меня не воспримут, всё-таки напишу.

Подумайте, что за задачи вы решаете?

Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?

Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?

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

Потом постоянные намёки на то, что нам нужно обязательно забрать всё одним запросом. Причём, неявно подразумевается что это благая цель которую все разделяют... ЗАЧЕМ?? У меня фетчер вообще забирает по 12 кажется msgid за раз, но он, наверное, самый быстрый из всех реализаций что я видел. Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.

Про ограничение на запрос. В лучшем случае в стандарт можно добавить рекомендацию про 8кб "стандарт" запроса, который в большинстве случаев совпадает с фактическим положением дел. Но расширение, которое будет показывать этот параметр, который вообще говоря доступен только веб серверу? Сами же простоту и элегантность хотите, нет? По 16 msgid забирать чистоплюство не позволяет? Значит, страдайте! :)

В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.

Моё мнение -- надо замораживать вариант драфта Андрея. А дальше, пилить альтернативный стандарт - если он будет хорош - ну значит его поддержит. Кто-то. Но в таком хаосе и горячке я точно не участник. Мне не нравится русло в которое все свернуло. Но это - неизбежно. Поэтому коммьюнити не будет. Никогда.

cUfxPL... . ОТВЕТИТЬ







\/ . shaos to shaos @ Re: Разбор idec 31/10/24 08:36

Вот почему в предыдущем сообщении оно только на последний ==== среагировало? Пустую строку надо до?

====
    again?
====


DpizUA... . ОТВЕТИТЬ









\/ . revoltech to Andrew Lobanov @ Re: Дополнения к стандарту 31/10/24 09:02

AL> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.

Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.

6pksCi... . ОТВЕТИТЬ



\/ . revoltech to hugeping @ Re: Дополнения к стандарту 31/10/24 09:09

hugeping> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?

Чтобы не качать лишнее.

hugeping> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?

В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.

hugeping> По 16 msgid забирать чистоплюство не позволяет?

Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.

Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.

hugeping> Моё мнение -- надо замораживать вариант драфта Андрея.

Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.

wlQOMG... . ОТВЕТИТЬ



\/ . tuple to hugeping @ Тест скорости фетча (+потеряшки) 31/10/24 09:37

hugeping> Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.

Активного участия в дискуссиях не принимал, но решил попробовать:

====
$ time ./ii-tool fetch https://club.hugeping.ru
INFO: 2024/10/31 12:20:50 Start fetcher(s) for https://club.hugeping.ru
INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/pipe.2032
INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/std.rein
...

real	0m30,322s
user	0m9,286s
sys	0m4,117s
====



При фетче были ошибки на некоторые сообщения, у которых обнаружили "wrong repto format":
- z8W283Fkra8J96OrKQCC
- TKcKYfkzLXg3YU3iMQrS
- nXdcHnk0Y4UunGNNUIwi
- VJPNtsUz2RhjJUXPAqZs
- GInGJYvgNySpTJGHmk8U
- 8vRmig2SXkHzCmgqFHOI
- XLMzTeZG3uvc9kJIjUpU
- 2xsAUpSzT1kmFLiAP7TN
- OANneaKiLh1Ft7Gx0NEP

Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?

6CP09V... . ОТВЕТИТЬ



\/ . hugeping to tuple @ Re: Тест скорости фетча (+потеряшки) 31/10/24 09:50

tuple> Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?

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

oRBMw0... . ОТВЕТИТЬ



\/ . hugeping to hugeping @ Re: Тест скорости фетча (+потеряшки) 31/10/24 09:54

hugeping> Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.

Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.

LJfaNY... . ОТВЕТИТЬ



\/ . hugeping to hugeping @ Re: Тест скорости фетча (+потеряшки) 31/10/24 09:58

hugeping> Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.

У этих сообщений repto не соответствует формату. Не 20 символов. Таки сообщения я стал дропать на приёме, после того случая недавнего. Но старые сообщения остались, видимо, битые.

xKKjRY... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Разбор idec 31/10/24 10:43

>> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.
ahamai> В бандле только эхи и msgid.

Ещё пустая строка.

ahamai> Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируй

Откуда оно там возьмётся?

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

645IVv... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 10:43

AL>> Не вижу в нём смысла.
revoltech> Как клиенту понять, сколько сообщений максимум можно забрать за один запрос?

Зачем ему это понимать?

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

mqIfbE... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 10:43

AL>> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
revoltech> Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.

Тут слайс, тут волшебное слово, тут хэш. Сиди, разбирай.

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

hxUYH5... . ОТВЕТИТЬ



\/ . Andrew Lobanov to hugeping @ Re: Дополнения к стандарту 31/10/24 10:43

hugeping> Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
hugeping> Но сдерживаться мне всё тяжелее конечно...
hugeping> Понимаю, что меня не воспримут, всё-таки напишу.
hugeping> Подумайте, что за задачи вы решаете?

[skipped]

Подписываюсь под каждым словом.

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

kUbqdw... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 10:43

shaos> Ну проблему нелогичности решает, на которую некоторые указывают :)

Нелогичность пока недоказана :)

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

Lw8pT9... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 10:43

shaos> Нету пробелов после ====
shaos> Он просто иногда работает, но чаще не работает
shaos> ====
shaos> here?
shaos> ====

А может, это от тех деятелей, которые \n\r шлют вместо \n? Попробуй поэкспериментировать с этим.

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

6K0jkz... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Разбор idec 31/10/24 10:43

shaos> Вот почему в предыдущем сообщении оно только на последний ==== среагировало? Пустую строку надо до?

Вангую, что это потому, что не было пустой строки в конце сообщения. Попробуй добавить и оно сломается совсем :)

shaos> ====
shaos> again?
shaos> ====

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

yRsGy1... . ОТВЕТИТЬ



\/ . Andrew Lobanov to hugeping @ Re: Разбор idec 31/10/24 10:43

shaos>> Неа - опять не сработало…
hugeping> Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )

По идее, это без разницы. $ -- это в любом случае конец строки.

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

eVDJWd... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 10:43

hugeping>> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
revoltech> Чтобы не качать лишнее.

Чтобы что?

hugeping>> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
revoltech> В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.

Лучше мурыжить все эхи пока все слайсы не уляжутся. И этот человек говорит мне о том, чтобы не качать лишнего. Будь последователен.

hugeping>> По 16 msgid забирать чистоплюство не позволяет?
revoltech> Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
revoltech> Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping>> Моё мнение -- надо замораживать вариант драфта Андрея.
revoltech> Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.

Они ни облегчат, ни усложнят жизнь. Просто придётся делать бесполезную работу.

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

oziDm3... . ОТВЕТИТЬ



\/ . revoltech to Andrew Lobanov @ Re: Дополнения к стандарту 31/10/24 10:53

AL> Зачем ему это понимать?

Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?

9RYLX6... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 11:26

AL>> Зачем ему это понимать?
revoltech> Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?

Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.

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

EDAPZh... . ОТВЕТИТЬ



\/ . hugeping to revoltech @ Re: Дополнения к стандарту 31/10/24 11:34

AL>> Зачем ему это понимать?

revoltech> Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?

Варианты:

1) tgstation считать аномалией и написать админу, чтобы он сделал "стандартные 8k" как рекомендовано в RFC: https://www.rfc-editor.org/rfc/rfc9110.html#section-4.1

It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.

2) Увидев это, задать параметр поменьше для фетча конкретно с tgi и оставить

3) Расширить станд.... ^W тьфу! :)

kraoFG... . ОТВЕТИТЬ





\/ . revoltech to Andrew Lobanov @ Re: Дополнения к стандарту 31/10/24 12:03

AL> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.

Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?

Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?

Fi3iAp... . ОТВЕТИТЬ



\/ . revoltech to hugeping @ Re: Дополнения к стандарту 31/10/24 12:06

hugeping> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.

Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?

cu5eKY... . ОТВЕТИТЬ



\/ . hugeping to revoltech @ Re: Дополнения к стандарту 31/10/24 12:25

hugeping>> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.

revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?

Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора. Так что я бы написал что-то вроде:

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

Главная мысль в том, что фетчер всё равно должен содержать в себе логику разбивки на запросы. А размер "пачки" -- дело второе. Я бы вообще > 16 или 32 не ставил бы никогда.

zwsHtR... . ОТВЕТИТЬ



\/ . revoltech to hugeping @ Re: Дополнения к стандарту 31/10/24 12:39

hugeping> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.

Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.

hugeping> Я бы вообще > 16 или 32 не ставил бы никогда.

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

DhnvGP... . ОТВЕТИТЬ



\/ . hugeping to revoltech @ Re: Дополнения к стандарту 31/10/24 12:53

revoltech> Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.

Ну там выше tuple скинул сколько полный фетч занимает времени с моей станции. А ты видел на чём она работает? ;) И сколько там в одном запросе? Так что я по прежнему не вижу проблем. Но раз кому-то очень важно, чтобы в одном запросе шло 380 сообщений, ну пусть так. Но в стандарте я бы явно не фиксировал эти числа. Написал бы про общую проблему.

t4rwlS... . ОТВЕТИТЬ







\/ . shaos to tuple @ Re: Дополнения к стандарту 31/10/24 16:46

> tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.

Ну может кого и просил, но мы с ним в сентябре 2022 года по е-мейлу договорились взаимно фетчить idec.talks и zx.spectrum, а потом я ещё bot.habr.rss у него начал забирать.

EyxTxq... . ОТВЕТИТЬ







\/ . revoltech to shaos @ Re: Дополнения к стандарту 31/10/24 16:52

shaos> Лучше написать не больше 380 т.к. вебсервер может такое не пережувать

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

shaos> И наверное надо метод POST добавить (я у себя добавлю)

Только за, но здесь почему-то нашлись принципиальные противники этой идеи.

AoMnqc... . ОТВЕТИТЬ





\/ . revoltech to shaos @ Re: Дополнения к стандарту 31/10/24 17:05

shaos> Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)

Да у самописных вообще ограничений нет обычно.

mckFZr... . ОТВЕТИТЬ





\/ . ahamai to revoltech @ Re: Дополнения к стандарту 31/10/24 18:26

Большие запросы вообще не нужны. Во-первых, они не нужны в принципе, я вообще не вижу разницы между запросами по 10 и по 40 сообщений, я и так и так легко выкачиваю всю сеть. Во-вторых, это ставит колом однопоточные серверы. Я бы запросы более 40 мессаг за раз расценивал бы как XAB.

NIDAeo... . ОТВЕТИТЬ





\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 18:36

AL>> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
revoltech> Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?

10+ лет качаем по 40. Полёт нормальный. Зачем выдумывать себе трудности? Чтобы героически их преодолевать?

revoltech> Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?

Настройки веб-сервера выходят за рамки стандарта.

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

apANwP... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 18:36

hugeping>> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?

Это уже прописано в стандарте. Только почему это должно быть прописано в стандарте IDEC?

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

x1LcOp... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 18:36

hugeping>> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
revoltech> Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.

Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.

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

FzZ2XP... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Дополнения к стандарту 31/10/24 18:38

shaos>> И наверное надо метод POST добавить (я у себя добавлю)
revoltech> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.

Эта идея решает примерно - проблем. Так зачем?

Могу добавить, оставив упоминание про потолок в 40 айдишников на запрос.

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

7hZDAd... . ОТВЕТИТЬ



\/ . ahamai to Andrew Lobanov @ Re: Разбор idec 31/10/24 18:34

> Ты хочешь в срезе получить нецелое количество сообщений? Зачем тебе точка в срезе? Типа, -12.5:12.5?

если точка в срезе, то старый софт будет воспринимать это не как непонятный msgid и падать с ошибкой его запросить, а как пустую эху и просто игнорировать. двоеточие можно уронить, 12..12. или нарисовать ху^W самолётик 12.:.12. это мелочи, но мелочи это именно то, что отделяет плохой дизайн от хорошего, когда всё предусмотрено заранее.

vfAqnG... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Дополнения к стандарту 31/10/24 18:59

> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?

Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 100 rss сообщений за час их и забрали, там 1 за неделю. а так это какая-то полумера, ни туда ни сюда.

> Потом, Рома трясёт своим ?sf=hash - как замену слайсов.

Приехали. Я не использую ?sf. Я не собираюсь использовать ?sf. Оно создано ровно для одного случая, работы в условиях медленного интернета. Для чего, как заявлялось, и делался idec. И, в отличие от idec, он делает ровно то, что от него просят, даёт одним запросом ровно то, что нужно, минимальный объём сообщений.

> На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим)

Не надо так делать. В 99% случаев запрос вернёт ровно то, что от него хотят. В остальных случаях, скорее всего, поможет только полный фетч.

> и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку.

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

> Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.

То, что называется слайсы, у меня называется lim. Сделано одной строчкой кода. Совместимо вообще со всем, не ломает /u/e/, и даже клиенты, которые понятия не имеют о lim, могут им пользоваться.

Адаптивный фетчинг это оверинжиниринг, программирование ради программирования, он вообще не даёт гарантий, в станциях где нет формальных эх а сортировка идёт по timestamp, могут быть вкинуты старые сообщения и такой фетчинг их не увидит. В нормальных условиях я вообще не вижу проблем гонять полные эхи, ибо только они дают полную гарантию. Для экономии трафка можно использовать ?h, его использование в гейтовании с shaos сократило дневной трафик с 12 мб до 2.

> В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.

Проблема была в проектировании. Некорректном дизайне. В сломе того, что просто работало и было простым, как три копейки, ради решения несуществующих проблем и каких-то непонятных смен стандарта, которые ничего не дают, кроме экономии трафика, которой тоже нет, потому что у тебя либо постоянные новые запросы, новые коннекции, новые строчки в логе сервера и так далее, да там tcp фреймы больше сожрут чем трафика сэкономится :)

Забавно, я посмотрел архив старых эх - я постоянно из протокола что-то выкидывал, пока не остались /e /m /u/e /u/m, и всё это не достигло предельной простоты. А щас только что-то добавляют. Да сколько угодно. Но не надо лезть в /u/e. Это база из баз, фейлбек из фейлбеков, он должен быть простым, примитивным, кодиться за три строчки кода на любом языке и быть единой везде. Расширяйте как хотите, но расширяйте отдельные методы, без x/feaures и прочего фиг пойми зачем, может нода работать по новому - запрашиваем, не может - фэлбэчимся на старое. Или это можно прописать в конфиге, например как здесь:

****
ii.about.2014
1396407760
51t
lenina,1
51t
Re: есть идея вообще всё нафиг переделать

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

1. сделать рядом с /z/ ещё одну (а не 8, как планировалось) реализацию, /u/ - без zlib и для обычного base64. /u/ должны будут поддерживать все серверы и все клиенты, всегда. /z/ - пока будет вотчина python, а там посмотрим.

2. так и сделать - вместо хттп://51t.ru/ писать хттп://51t.ru/z/. или хттп://51t.ru/u/. или даже хттп://мойсайт.ру/ii.php?q=/u/, по нему и определять, если на /z/ заканчивается - значит схема python, если на /u/ - значит плоская схема. для получения - всегда останутся /m/ и /e/

3. пока будет опциональным. пусть внедряется. :)
****

А стандарт обмена между станциями это стандарт обмена между станциями, пусть хоть на берёзовых бруньках обмениваются, это договорённости сисопов. Большие инконсистентные эхи - это проблема, которая была решена изначально, но потом заменена на другое решение, для которой и потребовались слайсы, чем больше изменений, тем больше новых сущностей. Это всё - плохой дизайн.

9Rn6bz... . ОТВЕТИТЬ



revoltech to Andrew Lobanov @ Re: Дополнения к стандарту 31/10/24 19:21

AL> 10+ лет качаем по 40. Полёт нормальный.

Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.

AL> Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.

Ну вот так бы сразу.

GTC7zm... . ОТВЕТИТЬ


1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 .23. 24 25 26 27 28 29 30 31 32