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






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

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

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

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







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

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

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

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



\/ . 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: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: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... . ОТВЕТИТЬ



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

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

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

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

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





\/ . 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... . ОТВЕТИТЬ



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

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

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

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

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



\/ . 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 10:43

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

Чтобы что?

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

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

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

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

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

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



\/ . 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 shaos @ Re: Разбор idec 31/10/24 10:43

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

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

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

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

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



\/ . 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> Ну проблему нелогичности решает, на которую некоторые указывают :)

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

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

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



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

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

[skipped]

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

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

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



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

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

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



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

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

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

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



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

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

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

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



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

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

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

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



\/ . 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... . ОТВЕТИТЬ



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

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

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

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

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

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

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

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

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

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

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



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

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

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

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









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

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

====
    again?
====


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







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

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

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

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

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

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

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

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

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

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

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

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



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

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

А зачем?

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

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



\/ . 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>> ну разве что если /x/e/...
revoltech> Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.

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

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

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



\/ . 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

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> Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...

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

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

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



\/ . 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 revoltech @ Re: Разбор idec 31/10/24 07:52

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

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

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

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



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

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

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

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



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

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

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

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

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



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

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

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

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



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

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

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





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

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

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

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



\/ . 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: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... . ОТВЕТИТЬ





\/ . 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... . ОТВЕТИТЬ



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

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

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

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

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

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

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

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



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

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

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

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

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



\/ . 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> Не надо драматизировать :)
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: тестовый архив 31/10/24 05:21

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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



\/ . 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 ahamai @ Re: игры в эхах 31/10/24 05:21

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

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

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

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



\/ . 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

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

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

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

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

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

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

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

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





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

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

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

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

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

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



\/ . 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 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 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... . ОТВЕТИТЬ



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

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

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



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

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

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





\/ . 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... . ОТВЕТИТЬ



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

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

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

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



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

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

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

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



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

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

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



\/ . 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 ahamai @ Re: тестовый архив 31/10/24 03:22

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

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

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



\/ . 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... . ОТВЕТИТЬ







\/ . ahamai to All @ Разбор idec 30/10/24 23:20

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

Формат /u/e был именно только для списка эх. Зачем добавлять туда что-то ещё? Почему не использовать, например /u/e?s=срез? Это значительно всё упрощает, это можно сувать куда угодно без разбора. А так алгоритм отдачи "всё эха" меняется на "последняя эха может быть не эхой":

ВЕСЬ ЗАПРОС СПИСОК ЭХ
ПОЛУЧИЛИ СПИСКИ
ЕСЛИ ЕСТЬ ЛИМИТ, УСТАНОВИЛИ

становится

ПОЛУЧИЛИ СПИСОК ЭХ
ПРОВЕРИЛИ ПОСЛЕДНЮЮ
ЕСЛИ ЭТО СРЕЗ, ТО РАСПАРСИЛИ СРЕЗ
СОХРАНИЛИ ЛИМИТ
УДАЛИЛИ ПОСЛЕДНЮЮ ЭХУ
ПОЛУЧИЛИ СПИСКИ
УСТАНОВИЛИ ЛИМИТ, ЕСЛИ ЕСТЬ

Команда lim появилась добавлением одного роута и одной строчки кода. Совместима с любым ii, хоть с ii-txt-0.1preprepre.

При этом корёжится список:
http://ii.blcat.ru/u/e/blcat.test/-100:100

ЧТО ТЫ ТАКОЕ? Эха? Нет точки, не эха. MSGID? по логике вроде бы да. У меня софт в расчёте на минималистичность и читаемость кода призван валиться при любых невалидных данных, а не разбираться, что это за ёжик.

Тут же появляется x/features. Это на каждый фетч надо ещё один запрос делать? Это не экономия трафика, это его расход. С какой-нибудь ?s= можно просто гонять url-ы и на любой клиент и на любой сервер, не задумываясь, поймёт ли он. А тут получается, надо прочитать x/features, потом подстроиться под сервера, давать ему срез или не давать. Лишний код, лишний трафик, лишнее переусложнение.

Сами же срезы не решают основной задачи "получить все нужные msgid одним запросом". Тебе нужно или обходить эхи по-очереди (привет, /e, от которого специально уходили для ускорения работы), или получать лишние сообщения. В стандарте не предусмотрено "хочу брать столько сообщений оттуда-то".

Кстати, ?sf потребовал добавления, по-моему, 4х строк кода и изменения одной. И он решает вопрос "получить только нужные msgid из нужных эх одним запросом".

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

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

ps. ?sf и ?h появились раньше, чем был сформирован стандарт iDEC.

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





\/ . ahamai to shaos @ Re: игры в эхах 30/10/24 20:51

тем более что sokoban игра с полной информацией и ходами только с одной стороны, её можно пройти одной командой

qNsQ3y... . ОТВЕТИТЬ







\/ . shaos to ahamai @ Re: игры в эхах 30/10/24 20:40

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

TgyRrg... . ОТВЕТИТЬ







\/ . ahamai to Andrew Lobanov @ Re: Срез 30/10/24 19:32

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

Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи. Почему не использовать что-то типа ?s=-100:100 или любой другой способ? Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения. Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?

Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез. Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных? А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться (поэтому links решал там, где opera не могла ни одного сайта открыть). Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно. Изначально были только /e и /m, но всё это было медленно и печально.

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



\/ . ahamai to ahamai @ Re: Срез 30/10/24 18:49

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

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



\/ . ahamai to revoltech @ Re: игры в эхах 30/10/24 18:44

> Можно передавать уровни сокобана в plaintext-формате (.sok).

это всё не так весело, тут играешь в одиночку. а я именно про игры всей компанией и совместную вовлечённость

557aj9... . ОТВЕТИТЬ



\/ . ahamai to Andrew Lobanov @ Re: Срез 30/10/24 18:42

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

реализация и sf и lim у меня это всего несколько строчек.

было

====
def echoareas(names):
out = ''
for ea in names:
out += ea + '\n' + get_echoarea(ea,True)
return out
====


стало

====
def echoareas(names, sf, lim=0):
out = ''
if sf: sf = set(sf.split('/'))
for ea in names:
dllist = get_echoarea_f(ea)
if sf:
newhash = [x for x in dllist if x in sf]
if newhash:
dllist = dllist[dllist.index(newhash[0]):]
if lim: dllist = dllist[-lim:]
dllist = '\n'.join(dllist)
if dllist: dllist += '\n'
out += ea + '\n' + dllist
return out
====



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

E8HPIq... . ОТВЕТИТЬ




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