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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[skipped]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы что?

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

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

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

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

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

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

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

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 тьфу! :)

hugeping> tgstation считать аномалией

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

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

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

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

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?

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 не ставил бы никогда.

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

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

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

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

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

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

Было несколько сообщение с 19-символьными msgid - я раньше писал про это.
Их можно вернуть в строй, добавив нолик в конце и поправив repto, где на них ссылаются.

Ну это веб-морда того же ii-php и шлёт :)

Балин!!! Точно!!! Спасибо!!!

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

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

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

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

Рекомендовать 32, но указать, что некоторые вебсервера могу принять до 380

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

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

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

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

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

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

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

Ну это как написать…

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

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

http://ii.blcat.ru/u/e/blcat.test/-100:100

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 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. пока будет опциональным. пусть внедряется. :)
****

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

Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &. Это, конечно, может задаватся в схеме, и это с точки зрения проектирования куда лучше, чем idec, но это не прозрачная замена, про php ноды я забыл.

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

Нормальным решением было бы завести свой неймспейс. Тем более, сеть это уже дважды проходила, сначала были /e и /m, но это было медленно и печально, запрос вещь дорогая, на самом деле даже дороже, чем лишний трафик. Потом была /z, потом была /u. И по урлу в конфиге указывалось, по какому протоколу работать. Точно так же можно было сделать и при развитии сети, какой-нибудь /r или /x, всё вынести в этот неймспейс. В случае чего (давайте представим этот дивный мир, где с /u/e ничего не сделали, он всё так же примитивен, как и был изначально) можно даже эмулировать старый интерфейс с неймспейсами /x/e и /x/m, если в старый клиент пропишут новую схему.

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

Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.

/u/m и /u/e это к тому, что это просто то, что осталось фундаментом, когда всё остальное было удалено для простоты. Тут кое-кто :) пытается переизобрести z/get, который был удалён из-за повышенной нагрузки на сервер, /u/e и /u/m это необходимый самодостаточный минимум, который вообще не должен меняться. А расширения - это то, что должно иметь возможность расширяться, а не хардкодиться в нескольких урлах, и что самое ужасное, при этом изменяя поведение базовых.

Я вообще не понял, к чему были эти изменения idec? Чтобы через 10 лет переизобрести их заново, потому что стандарт, предназначеный для расширения, оказывается не умеет расширяться? Это плохой дизайн. /u/e и /u/m при этом своей актуальности не утратили.

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

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

если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.

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

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

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

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

Уважаемый, я вот вроде тебя и понимаю, и не понимаю одновременно. Например, я пришёл сюда совсем недавно. Старую ii-документацию в этих ваших интернетах уже не сыскать, все старые сайты протухли. Откуда мне было знать про «эмпирическим путём найденный» лимит в 40 мессаг, про /z/get и прочие босфоры?

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

Здесь согласен.

ahamai> Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.

И здесь согласен.

ahamai> и что самое ужасное, при этом изменяя поведение базовых.

А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.

Другое дело, что логику парсера можно было бы упростить в разы, приняв концепцию железобетонной структуры key/value/key/value/..., но уже имеем то, что имеем.

ahamai> если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.

Это зависит от местоположения клиента и ноды. В стерильных тестовых условиях, может, и не вдвое быстрее будет. А вот в реальных время установки TCP/TLS-соединения тоже существенно добавляет к общей картине. Могу на днях замерять перефетч с shaos-а после уменьшения чанка с 389 сообщений до 40. Или с ping после уменьшения с 10000 до 40... Если интересно.

> А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.

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

Уже 10 лет у меня можно было получить сообщение по первым 6 символам его msgid. И никогда это не использовалось, хэш запомнить сложно. Поэтому на своей станции (в nastene-07 оно не пойдёт) и пока только через веб интерфейс сделал такой механизм - таглайн мемо. Он добавляет первые 6 символов хэша, а от остального хэша берёт остальные 14.

Если всё пойдёт по плану, то это сообщение будет доступно здесь: http://ii.blcat.ru/memo00

+++ memo:memo00

ahamai> это полностью ломает единость формата. /u/e должна быть везде, и должна реализовываться в 3 строках.

Так она и реализуется в 3-5 строках, если нормальные ЯП юзать. И поведение от запроса со слайсом на ноду, которая слайсы не реализует, меняться не будет: этот последний компонент просто не является валидным именем эхи. Нода, которая не умеет слайсить, должна его просто отбросить. Если она так не делает, чини реализацию.

> Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &.

Ну я ведь у себя поддержал list.txt?h=1 :)

Просто парсить надо будет вручную

> Так она и реализуется в 3-5 строках, если нормальные ЯП юзать. И поведение от запроса со слайсом на ноду, которая слайсы не реализует, меняться не будет: этот последний компонент просто не является валидным именем эхи. Нода, которая не умеет слайсить, должна его просто отбросить. Если она так не делает, чини реализацию.

1.
> ВЕСЬ ЗАПРОС СПИСОК ЭХ
> ПОЛУЧИЛИ СПИСКИ
> ЕСЛИ ЕСТЬ ЛИМИТ, УСТАНОВИЛИ
> становится
> ПОЛУЧИЛИ СПИСОК ЭХ
> ПРОВЕРИЛИ ПОСЛЕДНЮЮ
> ЕСЛИ ЭТО СРЕЗ, ТО РАСПАРСИЛИ СРЕЗ
> СОХРАНИЛИ ЛИМИТ
> УДАЛИЛИ ПОСЛЕДНЮЮ ЭХУ
> ПОЛУЧИЛИ СПИСКИ
> УСТАНОВИЛИ ЛИМИТ, ЕСЛИ ЕСТЬ

2. речь не о нормальных языках, речь о том, чтобы реализовать это в 3х шагах даже на posix shell и чтобы это было просто. ну не нужны там они нахрен, есть куча других неймспейсов, там пусть будут парсеры, шмарсеры и прочее. в чём проблема, запустил свой парсер, который можно расширять хоть до посинения, нету его - фалбакнулся. а "ну легко же реализовать" - это не дизайн. теперь туда включается и критерий "нужны нормальные языки". а сеть планировалась работать в аномальных условиях, хоть на дискете с openbsd. и для этого все протоколы простые. и не надо их усложнять, они не для того делались.

3.
ii.dev.2014
1396262024
51t
lenina,1
ksa242
Re: Адреса msgfrom/msgto
...
список - либо /e

номер
номер
номер

либо /z/e (у эхи есть символ ".", у номера сообщения - нет)

эха
номер
номер
номер
эха
номер
номер
номер
...

тут нет никаких "что-то ещё", либо эха либо msgid. когда "надо фильтровать", "надо разбирать последнюю эху" или что-то ещё надо, это вообще не про /u/e. там месяцы ушли, чтобы вырезать всё, что можно вырезать, чтобы прийти к такому предельно простому виду. этот протокол вообще не про проверки, он про примитивность. расширения должны быть расширениями. я вообще не понимаю, в чём проблема не трогать /u/e? мир перевернётся, если это будет какой-то другой запрос. к тому же, этих запросов был вагон и все в итоге оказались не нужны, на проблему повышенного трафика частично забили. ну сделайте нормальный api, с тем же key/value, расширяемый, позволяющий вольности, зачем лезть в /u/e ломая его единство - этот протокол уже определён, зафиксирован, и будет просто средством фалбака, максимально примитивным и рабочим средством, позволяющим общаться всему со всем. ему не нужны версии, он и так в идеальной стадии.. был

Ну расширенный слайсами /u/e существует уже тоже 10 лет и поддержан кучей клиентов и серверных реализаций - так что проще добавить одну проверку в blcat.ru дабы исключить падучесть и далее сосуществовать в мире и согласии :)

> Просто парсить надо будет вручную

это не есть прозрачная замена. прозрачная замена, это когда ты в любом клиенте просто прописываешь этот url вместо нужного, и ровно ничего не меняется кроме того случая, когда фильтр срабатывает, независимо от того, знает ли нода что-то или нет. если добавлять везде ?sf, то нода с запросом ?q=, ничего не знающая о ?sf, на запросе брякнется

вот /lim/ совместима с любыми существующими клиентами, просто меняешь url в конфиге и всё.

Я вообще не про это. Я про то, что не надо было трогать протокол, который для трогания совсем не предназначался. В чём проблема была вместо проверки x/feautures всяких просто использовать новый, а при отказе - фэлбекаться? Ну самый же очевидный дизайн. Зачем там, где всё было предельно просто, зачем-то совершенно ненужно это усложнять?