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> Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /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 всяких просто использовать новый, а при отказе - фэлбекаться? Ну самый же очевидный дизайн. Зачем там, где всё было предельно просто, зачем-то совершенно ненужно это усложнять?

или пойдёт. у меня уже столько расхождений между текущей станцией и 0.7, что надо на 0.7 переползать и уже в неё изменения вносить. в общем, вся хрень типа девочек-аватарок и advent удаляется, я перееду на 0.7

даже list.txt подстраивается

http://ii.blcat.ru/lim/100/list.txt

> тут нет никаких "что-то ещё", либо эха либо msgid.

… либо мусор

Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение - как POC для запуска в песочнице для ограниченного круга лиц - годится, а для реальных применений в массах - нет…

> Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение - как POC для запуска в песочнице для ограниченного круга лиц - годится, а для реальных применений в массах - нет…

ЕСЛИ МУСОР - ПАДАЙ. Не надо разбирать мусор. Топология сети такая, итить. Ты качаешь с доверенных узлов по предварительной договорённости. Формат бандла определён. Если оттуда летит мусор, то это уже красный код, не надо с него качать и не надо ничего разбирать, надо снимать с фетча.

Какое, итить, неработоспособное решение, если оно работает. Сколько раз повторять, что /u/e/ это базовый фалбак и он должен быть простым и легко воспроизводимым, нигде не должно быть проверки в коде и в стандарте. Как работает твой конкретный фетчер, по барабану. Есть базовая реализация, эталонная. И она должна быть максимально простая. И она должна быть одна.

Это базовый вопрос - НАХРЕНА ВЫ ЛЕЗЕТЕ В /U/E, ЕСЛИ ВЫ ТУПО ДАЖЕ НЕ ПОНИМАЕТЕ, ЧТО ЭТО И ЗАЧЕМ ЭТО НУЖНО???

ну я читаю такую ахинею
> Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение
и вижу люди тупо не понимают, о чём это вообще.

> а для реальных применений в массах - нет…
для каких млять применений в каких млять массах. ii это реализация строго конкретной задачи. основным критерием этой задачи является максимальная простота. НИКТО, НИКТО МЛяТЬ В ЦЕЛОМ СВЕТЕ НЕ МЕШАЕТ ТЕБЕ НАВЕШИВАТЬ СВОИ НАВОРОТЫ. Ну оставь ты млять в покое /u/e, это лингва франка, это база, это долгими бессонными ночами вытачивалось, чтобы удалить всё лишнее и оставить только базу, из которой можно свинтить что угодно, хоть босфор, хоть улисс - и никто при этом не трогал /u/e. Когда человечество вымрет и останутся только ветки и палки, чтобы можно было быстро собрать /u/e, как базовый компонент. И ПОЭТОМУ ОН МЛЯТЬ ДОЛЖЕН БЫТЬ ОФОРМЛЕН, ПРОСТ И ОДНОЗНАЧЕН, чтобы любая макака могла написать его реализацию. Любая. На любом языке. С любым млять навыком. Не мусор собирала.

И это млять не POC. Это и есть млять сама концепция сети. Нахрена переписывать базовый класс, наследуйся от него и потом пиши, как хочешь. А основные 4 стержня, которые работают в любых, любых млять условиях, они для того и сделаны такими простыми чтобы быть такими простыми. Без проверок, х..рок и прочей хрени. Обмен между нодами регламентируется ТОЛЬКО самими нодами. Могут хоть через git обмениваться и индексы по timestamp генерировать, это изначально была валидная версия обмена. Но помимо этого должна быть база, которая должна работать ВСЕГДА, ВЕЗДЕ, она должна быть МАКСИМАЛЬНО ПРОСТОЙ и МАКСИМАЛЬНО ВОСПРОИЗВОДИМОЙ. Поверх этого уже какие хошь расширения, это вообще пофиг, лишь бы клиент и сервер поддерживали. Но когда есть два стандарта на работу /u/e (один мой, другой неправильный (ц)) - это уже маразм.

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

+++ memo:marazm

Многие проблемы решаются кодом, а ещё большие её отсутствием. Плохой дизайн нельзя исправить кодом, или стандартами. Как пример это e-mail/smtp.

и да, если ты делаешь расширяемый формат, то делай его РАСШИРЯЕМЫМ. потому что кроме x:y это расширение не умеет, и добавить туда, не делая очередные псевдозаменители эх. Типа /эха/x;y/эха/x:y

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

/u/e и /u/m захаркожены в урлах именно потому что они топорные, примитивные и неизменяемые. у босфора был свой неймспейс /bb, который решал все задачи и слайсов, и ...яйсов. делай выборку так, как тебе хочется, делай проверку так, как тебе хочется. кода каждая проверка занимала примерно одну-две строчки. Поэтому любое расширение добавить дело было пары минут. И это расширение даже не надо делать мейнстримным, это может быть расширение, которое служит чисто для удобство обмена двух нод (как твой /h/x). И вообще ничего нигде не ломает и не хачит by design. Единый урл, который собирает все key/value в словарик, примерно как тэги в первой строке каждого ii сообщения типа repto, которые тоже позволяют развивать формат, добавляя свои тэги, которые не понимающие их станции игнорят (см. elp, там были тэги topicid и tags, и elp тоже отлично гейтовался в ii)

кстати, я нашёл в инете сырцы bosfor. поменять размер msgid с 11 до 20 и добавить обязательные точки в эхах - и будет вообще полноценная прозрачная замена, полностью совместимая с ii и при этом обладающая развитым api

хотя нет, чёт там всего много :)

> Ты качаешь с доверенных узлов по предварительной договорённости.

Каких нахрен доверенных узлов? Оно всё в интернет торчит голыми жопами - кто-то напишет сырой клиент который при переполнении чего-нибудь где-нибудь зашлет тебе дамп своей памяти вместо корректного запроса и чо?

> Каких нахрен доверенных узлов?

таких же как в фидо

> Оно всё в интернет торчит голыми жопами - кто-то напишет сырой клиент который при переполнении чего-нибудь где-нибудь зашлет тебе дамп своей памяти вместо корректного запроса и чо?

это некорректный url. он на этапе сервера отвалится. если url похож на корректный, то ты должен сформировать бандл. если хоть одна малейшая ошибка - ты падаешь. это очевидно. ты не должен пытаться анализировать некорректные данные, если узел, с которого ты фетчишь даёт некорректные данные, это 100% проблема этого узла. всё. зачем анализировать некорректные данные?

> которые не понимающие их станции игнорят

А вдруг не игнорят? Там ведь может быть только либо ii/ok, либо repto/msgid если там не ii/ok то это должно быть repto - где написано что там может быть мусор? :)

> А вдруг не игнорят? Там ведь может быть только либо ii/ok, либо repto/msgid если там не ii/ok то это должно быть repto - где написано что там может быть мусор? :)

парсинг сообщения это вообще другая тема, с запросом сообщений не связанная

а вообще, ii/ok там только для того, чтобы в любом случае не было пустой строки, которая где-нибудь может отфильтроваться.

если бы создатели сетевых протоколов всецело доверяли друг другу, то интернет бы давно умер…

> если бы создатели сетевых протоколов всецело доверяли друг другу, то интернет бы давно умер…

если бы все протоколы были одинаковые, они были бы не нужны, достаточно было бы одного

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

голдифицировал ябическую тему "Вестям Linux не нравится". На это ушло несколько недель, исправления адского форматирования, перевода с транслита. Из более 200 сообщений выбрал в итоге 89. Думаю, другие выбранные темы будут попроще.

глянуть можно здесь: http://ii.blcat.ru/rr/lor.gold/Ct8espwtEvwcPsbg9bTU

ну или тянуть lor.gold с меня :)

ёпт, там с пробелами беда. но в любом случае, это гораздо читаемее, чем было изначально.

> http://ii.blcat.ru/lim/100/list.txt

А это не изнасилование запроса /list.txt? ;)

это простая смена эндпоинта:

где было прописано http://ii.blcat.ru/u/, будет написано http://ii.blcat.ru/lim/100/u/

какая разница где эндпоинт задан? он всё равно записан в конфиге, и туда можно написать как первую строку, так и вторую. с запросом ровно ничего не делается, он ровно такой же. /list.txt, только эндпоинт другой

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

Ещё вопросы. Оказывается, нет возможности брать определённое количество сообщений из каждой эхи (я думал, это там было изначально). Это, оказывается, не нужно. Логично, в расширении, которое было сделано специально для экономии трафика, нет средств для экономии трафика. Тогда зачем нужен запрос, получающий количество сообщений в конкретных эхах? Что он даёт, для чего он, кто все эти люди.

На вопрос "где архив, где посмотреть сообщения за какой-то год" говорят "архив не нужен, эхи для общения". Это IRC для общения, а формат сохранения сообщения предусматривал их сохранение. Если это для общения, зачем тогда вообще нужны эхи на кучу тысяч сообщений, почему их не trunc-ать со старостью. То есть, в архив выгрузить эху нельзя, но старые сообщения хранить будем. Но будем рекомендовать их не выкачивать. Зачем делать распученые эхи, таская архивы, которые и не архивы вовсе. То есть, взяли идею "каждая эха это законченная капсула, которая или в активной работе или в архиве", потом сделали из неё чатилку, потом сделали средства бороться с оверхедом, которые это породило, сейчас надо бороться с последствиями последствий. Когда всё изначально работало ровно так, как задумано. Шарман.

Окей, если это средство общения, то зачем нужен стандарт. ДЛЯ КОГО он нужен? Что он стандатизирует. Что он декларирует: idec это чатилка или idec это для хранения сообщений на века или idec это для экономии трафика. Это разные вещи, а чатилка и на века вообще противоположные. Стандарт должен быть не для отношения нода-нода, тут вообще никогда стандарта не было, в этом и смысл гибкости сети, стандарт нужен был для написания новых клиентов и новых серверов. И он должен был давать что-то. Когда /u/e бывает и таким, и таким, это не стандарт. Когда возникает вопрос "если есть разное количество сообщений в эхах и надо их взять" и ответ "не нужно" - это не стандарт, есть механизм срезов но он неясен непосвящённому (мне, например, до сих пор неясен). И это в сети, которая была простой и элегантной. А этот неявный и грубый хак вообще неэлегантен - это именно хак. Я хочу чтобы непосвящённому объяснили про адаптивный фетч, чтобы он понял. Я, например, не понял. Про "сравнение двух списков и взятие элементов из одного, которого нет в другом" я могу объяснить даже пробегающей мимо кошке. Это основа дизайна сети и от неё все пляшет, поэтому это стандарт. А так, для каких софтописателей это стандарт, чтобы трём пользователям между собой общаться? А нафига вам стандарт-то нужен, сами не можете договориться?

>> Откуда оно там возьмётся?
ahamai> http://ii.blcat.ru/u/e/blcat.test/-100:100

А в телеграм такой запрос вообще ничего делать не станет.

Зачем в ii отсылать запросы idec?

+++ Caesium/0.4 RC1

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

Хороший дизайн это когда несуразные запросы не отрабатывают. Если ты пишешь наивный код это всегда будет плохой дизайн. Приведённые тобой запросы просто не будут работать даже в таверне, а там самый старый idec-софт.

Я не очень понимаю почему ты обход кривых запросов считаешь хорошим дизайном.

Как ii отработает /u/e/idec.talks/vfAqnGW9yupgQFEFzDk5 ? И почему?

+++ Caesium/0.4 RC1

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

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

Ну или я не понимаю как работает твой lim. Как им получить индекс эхи с 20 сообщения по 30?

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

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

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

Кто о чём, а Рома снова о том, что idec это не ii. Потому и не ii, что ii имел фундаментальные проблемы в дизайне.

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

В твой ii никто не лезет. Ты можешь взять хоть ii-0.3 и работать с idec. Но и ты в свою очередь не лезь в idec. Постоянно добавляют, это одни только слайсы. Если у тебя от них пригорает, просто не используй их. Нет, мы будем изобретать несовместимые со стандартом велосипеды.

Я даже больше скажу, никто не мешает фетчить ii в idec. Фетчер может не использовать слайсы вполне.

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

Он никогда не кодился за три строчки даже на петухоне. Я твою референсную реализацию читал.

ahamai> Расширяйте как хотите, но расширяйте отдельные методы, без x/feaures и прочего фиг пойми зачем, может нода работать по новому - запрашиваем, не может - фэлбэчимся на старое.

Рома, закопай уже стюардессу. Сабжа не будет. По крайней мере в стандарте. В плане обмена мой черновик останется без изменений. Изменения будут только в сопроводительном тексте для устранения неоднозначностей.

Кто что для своих фантазий сделает у себя не имеет значения пока он соблюдает стандарт.

+++ Caesium/0.4 RC1

AL>> 10+ лет качаем по 40. Полёт нормальный.
revoltech> Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.

Готовый софт уже делал так. Всё на гитхабе есть - бери и смотри, раз уж начал своё писать.

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

Договорились.

+++ Caesium/0.4 RC1

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

В рамках idec она везде. То, что ты не соблюдаешь стандарт - исключительно твоя проблема.

+++ Caesium/0.4 RC1

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

Праада она не решает задач слайсов. И делает адаптивный фетчинг удобным. Зато в отдельном неймспейсе ага.

+++ Caesium/0.4 RC1

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

Будь последовательным. Твой ii никто не трогает. Просто на его основе сделали нечто другое. Всё строго по твоим заветам из 2014-го. А то сперва ты говоришь одно, потом приходишь и вдруг оказывается, что то, что ты говорил, не имеет значения. Почему тогда то, что ты говоришь сейчас, вдруг должно иметь значение? Завтра ты опять переобуешься и снова будешь делать вид, что ты не говорил того, что говоришь сегодня.

+++ Caesium/0.4 RC1

>> тут нет никаких "что-то ещё", либо эха либо msgid.
shaos> … либо мусор
shaos> Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение - как POC для запуска в песочнице для ограниченного круга лиц - годится, а для реальных применений в массах - нет…

Очень правильные слова.

ЗЫЖ А где посмотреть на ноду на шелле. А то Рома бьёт себя пяткой в грудь, а ноду на шелле не видать.

+++ Caesium/0.4 RC1

ahamai> Какое, итить, неработоспособное решение, если оно работает. Сколько раз повторять, что /u/e/ это базовый фалбак и он должен быть простым и легко воспроизводимым, нигде не должно быть проверки в коде и в стандарте. Как работает твой конкретный фетчер, по барабану. Есть базовая реализация, эталонная. И она должна быть максимально простая. И она должна быть одна.

Где взять эталонную реализацию?

ahamai> Это базовый вопрос - НАХРЕНА ВЫ ЛЕЗЕТЕ В /U/E, ЕСЛИ ВЫ ТУПО ДАЖЕ НЕ ПОНИМАЕТЕ, ЧТО ЭТО И ЗАЧЕМ ЭТО НУЖНО???

Нахоена ты своими ii-ручонками лезешь в idec, если ты тупо даже непонимаешь что это и зачем это нужно?

ahamai> ну я читаю такую ахинею

Ты её пишешь. В больших количествах.

ahamai> и вижу люди тупо не понимают, о чём это вообще.

Да. Некоторые не понимают о чём idec. Застряли в 2014, на эхотаг не смотрят, лезут с какими-то левыми фичами.

>> а для реальных применений в массах - нет…
ahamai> для каких млять применений в каких млять массах. ii это реализация строго конкретной задачи. основным критерием этой задачи является максимальная простота. НИКТО, НИКТО МЛяТЬ В ЦЕЛОМ СВЕТЕ НЕ МЕШАЕТ ТЕБЕ НАВЕШИВАТЬ СВОИ НАВОРОТЫ. Ну оставь ты млять в покое /u/e, это лингва франка, это база, это долгими бессонными ночами вытачивалось, чтобы удалить всё лишнее и оставить только базу, из которой можно свинтить что угодно, хоть босфор, хоть улисс - и никто при этом не трогал /u/e. Когда человечество вымрет и останутся только ветки и палки, чтобы можно было быстро собрать /u/e, как базовый компонент. И ПОЭТОМУ ОН МЛЯТЬ ДОЛЖЕН БЫТЬ ОФОРМЛЕН, ПРОСТ И ОДНОЗНАЧЕН, чтобы любая макака могла написать его реализацию. Любая. На любом языке. С любым млять навыком. Не мусор собирала.
ahamai> И это млять не POC. Это и есть млять сама концепция сети. Нахрена переписывать базовый класс, наследуйся от него и потом пиши, как хочешь. А основные 4 стержня, которые работают в любых, любых млять условиях, они для того и сделаны такими простыми чтобы быть такими простыми. Без проверок, х..рок и прочей хрени. Обмен между нодами регламентируется ТОЛЬКО самими нодами. Могут хоть через git обмениваться и индексы по timestamp генерировать, это изначально была валидная версия обмена. Но помимо этого должна быть база, которая должна работать ВСЕГДА, ВЕЗДЕ, она должна быть МАКСИМАЛЬНО ПРОСТОЙ и МАКСИМАЛЬНО ВОСПРОИЗВОДИМОЙ. Поверх этого уже какие хошь расширения, это вообще пофиг, лишь бы клиент и сервер поддерживали. Но когда есть два стандарта на работу /u/e (один мой, другой неправильный (ц)) - это уже маразм.

Рома, иди проспись. Где ты увидел ii, млять. Это так печально, что интернетом пользуются те, кто так и не научился читать.

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

Ты сделал слишком много ошибок в словосочетании "довели до ума мёртворождённое недоразумение".

+++ Caesium/0.4 RC1

Сабж. Опять. Ставлю на него твит, так как читать этот бессвязный поток сознания, оторванный от реальности, уже нет сил.

+++ Caesium/0.4 RC1

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

Немного не так. Точнее, совсем не так. То, что ты написал — это манипуляция. «ЕСЛИ ЕСТЬ ЛИМИТ, УСТАНОВИЛИ» тоже не из одного пункта состоит, его тоже надо где-то взять и распарсить. Это раз. Два — «распарсили срез» — это одна операция. Правильнее было бы слегка иначе:

1. Получили список эх (сохранили путь, разделив его по /).
2. Взяли последнюю.
3. Если там есть двоеточие, сохранили всё до него в смещение и всё после него в лимит.
4. Удалили из списка ВСЕ невалидные имена эх (u и e тоже таковыми являются, не только слайс).
5. Выгребли списки из базы по уже установленному лимиту.

Пять шагов. Корректных.

AL> ЗЫЖ А где посмотреть на ноду на шелле.

Могу сделать хоть на busybox sh (+ busybox nc + busybox sed, возможно), но зачем? Это будет лютый тормоз. Как и связка busybox awk + busybox nc.

Если брать продвинутый шелл вроде bash или oksh, всё можно сделать непосредственно в нём, кроме самой отдачи по TCP. Я, блин, гофер-клиента на чистом баше не так давно делал (Bopher-NG), вопрос только, что это решает.

AL> А то Рома бьёт себя пяткой в грудь

Это от неосиляторства инструментов, не более. Я вот довольно быстро согласился и с 40 айдишниками вместо 380, и с контекстным парсингом /u/e вместо ключ/значение, поскольку принципиально это мало что меняет (алгоритмически тут можно всё тотально упростить, но для этого надо отказаться от обратной совместимости, иначе смысла немного). Те же вещи, на которых настаивает Рома, предложены даже не с позиции оптимизации, а с позиции «лишь бы существующий кривой код не чинить». Противно.

За 10 лет каких то продвижений и изменений нет. И да, я 100% уверен, что я хотел сказать. Ибо умные люди притчами говорят, а глупые в них за частности цепляются, не видя целого.

Зато у вас новый стандарт будет. Ура!

Можно вопрос. На каких вещах я настаиваю. Хоть на одной. Хоть на одной единственной,? Я ВООБЩЕ НИЧЕГО НЕ ПРЕДЛАГАЮ. НИЧЕГО. НИЧЕГО. Неужели это так трудно заметить? Я только разбираю кривой дизайн idec 10 летней давности. Всё. То есть это абсолютно всё. Как можно увидеть то, чего нет вообще, мне непонятно.

У меня тогда две. Там три строки понятного прозрачного кода.

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

И это вы раздули тему, рассуждая о том, что я не говорил. Я надеялся на обсуждение типа тут сделано так, тут сделано так. А разговор ушёл в тему тут сделано так потому что тут сделано так. И прочего лишнего. Разговор от ДИЗАЙНА перешёл к ДЕТАЛЯМ и РЕАЛИЗАЦИЯМ. Эта тема меня вообще не интересовало но каждый начинает лезть в неё. Боюсь, вы вообще не поняли, о чём я. Потому что вы не делали Дизайна проекта, принимая много решений "как поступить", а базируетесь на уже готовой реализации, когда те решения, которые есть, кажутся уже сами собой разумеющимися.

Разговор на ту тему, что мне интересно, вас вытянуть не удалось, вы сразу переходите на совсем другую, мне неинтересную, и которая вообще ничё не даёт. Впрочем, в текущем статусе стандарт вообще ничего не даёт.

ahamai> Можно вопрос. На каких вещах я настаиваю. Хоть на одной. Хоть на одной единственной,?

На изменении формата срезов, например. Как минимум на выносе оных из /u/e.

В моём варианте реализации /u/e (из 5 пунктов) нода, которая не умеет срезы, просто их проигнорирует как невалидное имя эхи, и отдаст все сообщения из запрошенных эх. Это так сложно?

ahamai> Зато у вас новый стандарт будет. Ура!

А старый (до IDEC) где почитать-то? Или опять в ИМХОдники будут тыкать?

ahamai> У меня тогда две. Там три строки понятного прозрачного кода.

Ну скинь эти три строки тогда. Почему-то уверен, что всего необходимого там не будет.

ahamai> Потому что вы не делали Дизайна проекта, принимая много решений "как поступить", а базируетесь на уже готовой реализации, когда те решения, которые есть, кажутся уже сами собой разумеющимися.

С моей колокольни стороннего наблюдателя и имплементатора мне важны чётко документированные элементы протокола и как бы всё. С точки же зрения дизайна здесь, как говорится, есть два стула: либо ломаем вообще всю обратную совместимость и радикально упрощаем протокол (а упрощать и правда есть куда даже после выпиливания кучи эндпоинтов из стандарта), либо же проще оставить как есть, т.к. любые оптимизации ПРИ сохранении обратной совместимости приведут только к усложнению.

А почему так криво задизайнили в 2014 — это уж точно вопрос не ко мне. Но сейчас это приходится принимать как данность. Или же ломать совместимость полностью и делать как следует. Но тогда это уже будет другая сеть.

> А почему так криво задизайнили в 2014 — это уж точно вопрос не ко мне. Но сейчас это приходится принимать как данность. Или же ломать совместимость полностью и делать как следует. Но тогда это уже будет другая сеть.

так об этом то и речь! речь не о проектировании, речь о проблеме проектирования! для чего я все последние дни весь 2014 год в ретроспективе пересказал!

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

можно простым способом решать 97% задач, а можно накодить ещё и решить 99.9% задач. это разные подходы.

ii не умел "экономить трафик"

ahamai> Проблема собственно только в том что вы проблемы не видите. Только и всего.

С /u/e проблемы действительно нет. Невалидные имена эх должны отбрасываться, даже если нода не умеет слайсы, она просто этот последний пункт выкинет и отдаст содержимое всего остального.

Если у тебя это не так, чини ноду.

> Ну скинь эти три строки тогда. Почему-то уверен, что всего необходимого там не будет.

url.split('/')
for ea on this
out.append([ea] + open('e/ea').splitlines()]

не суть важно. я уе привёл именно как пример разных реализаций. про /u/e я могу понятно, на пальцах и в деталях рассказать всю детализацию домохозяйки. её реализацию осилит почти любой, кто осилил команду cat. а вот парсер со срезами я сейчас на sh/bash и не напишу, надо будет смотреть много документации и вспоминать. "простота" - это не про осиливать, простота это когда осиливать не надо, и технический порог входа минимальный. при введении доп элементов вступают новые критерии.

если для чего-то нужно 2 навыка, то под этот фильтр может попасть 80% людей. а если их, скажем, 5, которые чуть посложнее, то с каждым новым фильтрация будет гораздо сильнее (команду cat на лоре осилило процентов 99, а парсеры на sh - процентов 20-40). для того, чтобы не понимать, достаточно не знать одного навыка - например я знаю 4 из 5, но я не понимаю, как работают срезы, потому что в разных языках разные нумерации, и я этого просто не понимаю.

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

я не говорю, какой путь правильный - правильного пути нет. я говорю о том, как изменилось ПРОЕКТИРОВАНИЕ ii при переходе в idec. Правильно-неправильно, хорошо-плохо - это вообще не важно. Раз тут началась тема с новым стандартом, я просто хотел напомнить 2014, когда делали расширения для ii, чтобы экономить трафик. Почему все на внешнее смотрит и ни один вообще не посмотрел вглубь? Зачем код, причём здесь код. 10 лет назад делали расширение. Я напомнил, как это было, в деталях. Расписал отличия и недостатки НА МОЙ ВЗГЛЯД. Из этого, блять, вообще не следует, что это недостатки для других. Я ПРО РАЗНИЦЫ ПОДХОДОВ. Если кто-то говорит, что старые /u/e и новые одинаково простые, он вообще не с той стороны смотрит. Но с другой стороны так никто и не посмотрел. Ладно. Кто как хочет, тот так и делает, жаль только обсуждение сразу ушло в совсем другую сторону. Но зато сейчас ты знаешь историю в ретроспективе, подумай об этом :) Ну или может кто ещё зайдёт и подумает.

> Если у тебя это не так, чини ноду.

я не могу починить референсную ii 0.3, которая является базовым и законченным стандартом ii, потому что она осталась в 2014 году

ps. проблема не в /u/e

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

В современном мире применителя второго подхода взломают за считанные дни. Забывать о таком подходе надо.

ahamai> > Ну скинь эти три строки тогда. Почему-то уверен, что всего необходимого там не будет.
ahamai>
ahamai> url.split('/')
ahamai> for ea on this
ahamai> out.append([ea] + open('e/ea').splitlines()]

Даже не вчитываясь в on вместо in... А где здесь проверка на то, что тебе валидные имена эх подсунули? Хотя бы на наличие точки и длину от 3 до 120 символов?

В общем, как раз то, о чём я и говорил.

ahamai> вот парсер со срезами я сейчас на sh/bash и не напишу

А я напишу, но зачем?

ahamai> Но зато сейчас ты знаешь историю в ретроспективе, подумай об этом :) Ну или может кто ещё зайдёт и подумает.

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

> Даже не вчитываясь в on вместо in... А где здесь проверка на то, что тебе валидные имена эх подсунули? Хотя бы на наличие точки и длину от 3 до 120 символов?

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

> В общем, как раз то, о чём я и говорил.

Нет. это то, о чём я говорил. Последние несколько дней.

> Не понимаю, чем это знание мне поможет в плане грядущей реализации своей ноды.

оформление полиси, соглашений, стандартов и прочего - это вообще не технология. это политика. сначала политика определяет стандарты, потом стандарты технологию. так было с ii. дважды.

Блин. я специально старался писать не ответы, а новые темы, чтобы не было обсуждение деталей, а всё опять сходится к обсуждению деталей. :)

> В современном мире применителя второго подхода взломают за считанные дни. Забывать о таком подходе надо.

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

Ещё в первоначальной версии было написано, что сторонники обоих подходов считают свой подход единственно верным.

Зря я две этих строчки удалил, видимо, хотя мне казалось, что так будет лучше :)

ps. Я считаю, что правильного подхода не существует.

Вот чего я родил - всем сестра'м по серьга'м как говорится :)

elseif ($opts[0] == 'u' and $opts[1] == 'e') {
	$work_options=array_slice($opts, 2);
	$aecho = [];
	$aoff = [];
	$alen = [];
	$lim = 0;
	$count = 0;
	foreach ($work_options as $work) {
		if(is_numeric($work)) {
			if($lim >= 0) die("error: unexpected single number");
			$lim = intval($work);
			if($lim < 0) die("error: unexpected negative number");
		} elseif(strpos($work,".")!==false) {
			if($lim < 0) die("error: missing lim value");
			array_push($aecho,$work);
			if($lim > 0) {
				array_push($aoff,-$lim);
				array_push($alen,$lim);
			} else {
				array_push($aoff,NULL);
				array_push($alen,NULL);
			}
			$count = $count + 1;
		} elseif(strpos($work,":")!==false || strcmp($work,"all")==0 || strcmp($work,"last")==0) {
			if($lim != 0) die("error: slice can not be used with lim");
			if(strcmp($work,"all")==0) {
				$a = 0;
				$b = 0;
			} elseif(strcmp($work,"last")==0) {
				$a = -1;
				$b = 1;
			} else {
				$numbers=explode(":", $work);
				$a = intval($numbers[0]);
				$b = intval($numbers[1]);
			}
			for($i=$count-1;$i>=0;$i--) {
				if(!is_null($aoff[$i])) break;
				$aoff[$i] = $a;
				$alen[$i] = $b;
			}
		} elseif(strcmp($work,"lim")==0) {
			$lim = -1;
		} else die("error: wrong arguments");
	}
	$buffer = "";
	for($i=0;$i<$count;$i++) {
		$echo = $aecho[$i];
		if($aoff[$i]==0 && $alen[$i]==0) {
			$slice = $access->getMsgList($echo); // NULL, NULL
		} else {
			$slice = $access->getMsgList($echo, $aoff[$i], $alen[$i]);
		}
		if (count($slice) > 0) {
			$buffer.=$echo."\n".implode("\n", $slice)."\n";
		} else {
			$buffer.=$echo."\n";
		}
	}
	echo $buffer;
}

тут тебе и стандартный ii, и со слайсами в конце [-]N:M как в IDEC, и со слайсами внутри (между именами эх) как я предлагал ранее, и можно писать last вместо -1:1, и можно писать all внутри если в конце стоит last или какие другие нумера (типа /u/e/echo.1/all/echo.2/echo.3/last если надо только последнее сообщение для последних двух эх и всё для первой), и можно после каждой эхи писать, как предлагал revoltech, и даже lim/N в начале пройдёт как у Ромы (правда при этом уже нельзя будет слайсы воткнуть), а вот от msgid и далее делать неохота ибо оно криво будет работать т.к. порядок может быть чуть разный на разных нодах...

ahamai> я не помню, есть echo_flt в том коде, но это вообще неважно.

Важно. Поскольку это уже не три строчки.

ahamai> лишнего оно не запросит а на неккоректное просто упадёт.

А надо, чтобы не падало, а игнорировало такие имена.

ahamai> оформление полиси, соглашений, стандартов и прочего - это вообще не технология.

Ну дык. Без чёткого ТЗ результат всегда ХЗ.

ahamai> Я не добавил фразу "как эту задачу решают программист и непрограммист"

Непрограммисты (хотя ХЗ, что ты в это слово вкладываешь) обычно в такие вещи просто не лезут.

ahamai> я, например. не программист

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

AL>> ЗЫЖ А где посмотреть на ноду на шелле.
revoltech> Могу сделать хоть на busybox sh (+ busybox nc + busybox sed, возможно), но зачем? Это будет лютый тормоз. Как и связка busybox awk + busybox nc.

Вопрос то не в теоретической возможности. Вот Рома писал про ноду на шелле и, мол, там это сделать сложно (непонятно почему, правда). Но не показал этой мифической ноды, где это сделать сложно.

revoltech> Если брать продвинутый шелл вроде bash или oksh, всё можно сделать непосредственно в нём, кроме самой отдачи по TCP. Я, блин, гофер-клиента на чистом баше не так давно делал (Bopher-NG), вопрос только, что это решает.
AL>> А то Рома бьёт себя пяткой в грудь
revoltech> Это от неосиляторства инструментов, не более. Я вот довольно быстро согласился и с 40 айдишниками вместо 380, и с контекстным парсингом /u/e вместо ключ/значение, поскольку принципиально это мало что меняет (алгоритмически тут можно всё тотально упростить, но для этого надо отказаться от обратной совместимости, иначе смысла немного). Те же вещи, на которых настаивает Рома, предложены даже не с позиции оптимизации, а с позиции «лишь бы существующий кривой код не чинить». Противно.

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

Почему ii ходит в idec по своим стандартам я могу понять. Но idec позволяет работать в ii-режиме и вообще не обязан использовать слайсы при фетчинге. Но не в голове у Ромы.

Короче, я забодался и Рома идёт лесом со своим странным нытьём. Ходить с ним кругами смысла нет, полезной нагрузки в его сообщениях нет, наезды и истерики в его сообщениях есть. Ну и нафейхоа? Пока добавил в цезий кривой и косой, но механизм твитов. Доработаю и выдам на суд общественности.

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

shaos> Вот чего я родил

«...А глянешь — мамочка моя! Эт чё? О чём? А набуя?» ©
Не, прочесть-то можно (хотя да, этот код напомнил, почему я пых терпеть не могу), но вот это как раз тот уровень сложности, от которого я стараюсь держаться подальше. Могу в отдельном сабже сделать разбор сего шындевра. Но у меня в ноде такого не будет точно.

shaos> а вот от msgid и далее делать неохота ибо оно криво будет работать т.к. порядок может быть чуть разный на разных нодах...

Такого, кстати, быть не должно.

> это как раз тот уровень сложности, от которого я стараюсь держаться подальше.

Это сложность по твоему? Это наоборот лёгкость и непринуждённость :)

> Такого, кстати, быть не должно.

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