В связи с "родовыми травмами ii", про которые мы, без сомнения знаем, и некоторым сомнениям в отношении решений, принятых Ромой в рамках его нового проекта, у меня появилось желание расширить стандарт ii для улучшения нашей сети.

Мои предложения просты:
* в формате данных оставить всё как есть;
* оставить бандлы, так как это очень полезная штука и она однозначно пригодится;
* фетчинг сделать разным: забрать всё, забрать сколько-то последних сообщений в эхе, забрать всё, после уже имеющихся сообщений в локальной базе;

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

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

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

Идея номер один.

Надо дать возможность клиенту гибко забирать произвольное число сообщений. Уже реализовано следующее поведение ноды.

Расширение схемы /u/e.

В случае работы простого фетчера, схема работает по-старому: указываем схеме эхоконференции через / и получаем все сообщения из всех указанных эхоконференций.

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

Для наглядности:

/u/e/ii.14/pipe.2032 вернёт все сообщения в этих двух эхах.

/u/e/ii.14/pipe.2032/20 вернёт последние 20 сообщений из этих эхоконференций.

http://95.129.164.24/gitphp/?p=iing.git

Реализация ноды с поддержкой указанного ранее расширения на python3. Пока безз веб-морды, но нам же для тестирования новых идей, а не на рабочие сервера накатывать =)

Надо клиент доработать. Пока думаю сделать для простоты на базе своего iitxt поддержку расширения /u/e (там даже /e расширено да) и несколько вариантов получения сообщений.

> Корень моего предложения прост: избавиться от суффиксов и перекатывания эх, оставив всё максимально совместимым с тем, что мы имеем.
А я предлагаю суффиксы не убирать, а сделать _необязательными_. Перекатывание тоже лучше на первое время оставить на обычные эхи, но на какую-нибудь болталку ради тестирования убрать. И ещё сделать длину msgid от $n (это может быть как 12 для совместимости, так и сколько угодно) до 40 знаков, но по дефолту оставить 20.

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

Предлагаю понятие "столько-то последних" расширить: взять не обязательно последние, а n первых, от k до n и так далее. Проще говоря, как списки в питоне. "Забрать всё после определённого msgid" тоже можно сделать.

И не забыть, кстати, реализовать расширение сисопофайлов, которое ты предлагал =)

>А я предлагаю суффиксы не убирать, а сделать _необязательными_.
Так оно то на то и выйдет. Просто название эхи можно будет делать и просто im и ii.14. С точки зрения ноды или клиента не будет никакой разницы в этих двух названиях.

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

>И ещё сделать длину msgid от $n (это может быть как 12 для совместимости, так и сколько угодно) до 40 знаков, но по дефолту оставить 20.
Вот это не понял. Какой толк в регулируемой длинне msgid? 20 знаков оставляют нам 36^20 уникальных идентификаторов. Столько сообщений на ЛОРе нет со всей его 26-летней базой. Конечно, ничего сложного в такой реализации нет и я без проблем могу длинну msgid, присваиваемых нодой, сделать регулируемой через конфиг. Хоть 60 знаков, хоть 5. В принципе, это не противоречит идеологии, но внесёт некоторый разброд. Тут или рекомендации для нод в сети выпускать или жестко фиксировать. В общем, посмотрим. Пока сделаю регулируемую длинну.

>> * фетчинг сделать разным: забрать всё, забрать сколько-то последних сообщений в эхе, забрать всё, после уже имеющихся сообщений в локальной базе;
>Предлагаю понятие "столько-то последних" расширить: взять не обязательно последние, а n первых, от k до n и так далее. Проще говоря, как списки в питоне. "Забрать всё после определённого msgid" тоже можно сделать.
Очень интересное предложение. Попробую сегодня-завтра вписать это в стандартную схему /u/e, совместимую с версией 0.3.

>И не забыть, кстати, реализовать расширение сисопофайлов, которое ты предлагал =)
Хоть убей не помню о чём речь. Напомни пожалуйста.

>> Хоть убей не помню о чём речь. Напомни пожалуйста.
>/x/file или что-то подобное. Где поинту выдаётся список файлов ноды и возможность их скачать с помощью authstr.
Фреки (freq -- file request) =) Сделаю сразу в новую реализацию, дабы не распыляться.

>> Какой толк в регулируемой длинне msgid?
>Просто ради совместимости. А то тут по 100500 стандартов всякие делают, что потом гейтоваться трудно. Мне, если честно, так и хочется 20 оставить.
Речь о совместимости с новой Роминой сетью? Тогда всё ещё проще. Достаточно не считать сообщением всё, что не имеет len(msgid) != 20 и всё. Заодно всё таки сделаю опцию в конфиге для указания длины назначаемых нодой msgid.

>> Сперва я сделаю отдельную тестовую ноду для обкатки технологии. Может даже не буду её сообщать с существующей сетью.
>А я в таком случае опять за возрождение ветки features =) Торопиться ведь тоже не надо.
PHP-нода тоже очень нужна. Мне она уже не столь актуальна, но я с теплотой вспоминаю те времена, когда она была единственным вариантом для меня. Сейчас всё таки сделаю редирект и перееду на домашний сервак. Может даже куплю домен себе какой-нибудь.

> Речь о совместимости с новой Роминой сетью?
Именно. Этот вопрос по msgid я не по технической составляющей поднял, а по социальной. Ты же прекрасно помнишь, как всё было раньше (в том числе его периодические, хмм, неприятные уходы), и тут довольно трудно решить, как правильно, а как нет.

> PHP-нода тоже очень нужна. Мне она уже не столь актуальна, но я с теплотой вспоминаю те времена, когда она была единственным вариантом для меня.
Мимими :3, приятно такое читать =) Лично я продолжу её использовать, потому что помню каждый кусок кода в ней, и там удобно всё подряд менять/улучшать/и.т.д.

>Предлагаю понятие "столько-то последних" расширить: взять не обязательно последние, а n первых, от k до n и так далее. Проще говоря, как списки в питоне. "Забрать всё после определённого msgid" тоже можно сделать.
В догонку. Как думаешь, лучше сделать синтаксис один в один питоновский или упростить немного?

Например:
/u/e/ii.14/10: - 10 первых
/u/e/ii.14/:10 - 10 последних
/u/e/ii.14/10 - 10 последних
/u/e/ii.14/10:20 - с 10 по 20 сообщения в эхе?

По усти этого уже более чем достаточно для произвольных запросов в эху, но можно "раскошелиться" и реализовать 1 в 1 питоновский синтаксис выборки из списка. Правда он будет сложнее для людей, не привыкших к питону, а у нас простота не только реализации, но и использования во главе угла, ЕМНИП.

> Как думаешь, лучше сделать синтаксис один в один питоновский или упростить немного?
Думаю, лучше будет упростить

-10 - 10 последних
10 - 10 первых
10:20 - с 10 по 20
-10:5 - с десяти последних по 5

или как в сишном клиенте

l10 - last 10 messages
f5 - first 5 messages
r2:4 - from 3rd to 5th (including)

, но from -> to нужно расширить до значений с конца списка

>Именно. Этот вопрос по msgid я не по технической составляющей поднял, а по социальной. Ты же прекрасно помнишь, как всё было раньше (в том числе его периодические, хмм, неприятные уходы), и тут довольно трудно решить, как правильно, а как нет.
Честно говоря, даже то небольшое сообщение с сетью ulis мне не показалось ни полезным ни интересным. Вкупе с периодическими неконструктивными разборками, которые Рома устраивает (а я настолько слабая личность, что ведусь и вступаю в полемику), не вижу большого смысла гейтоваться с его сетью. Но чисто технически ничего сложного в этом нет и моя нода будет обрабатывать сообщения с любыми msgid.

>> Как думаешь, лучше сделать синтаксис один в один питоновский или упростить немного?
>Думаю, лучше будет упростить

>-10 - 10 последних
>10 - 10 первых
>10:20 - с 10 по 20
>-10:5 - с десяти последних по 5

Может последний вариант сделать в виде 5:-10? Так будет логичнее запись запроса и неофит не будет ждать развёрнутый задом на перёд список (как я ненавижу это в рескане фидошных эх) =)

> Может последний вариант сделать в виде 5:-10? Так будет логичнее запись запроса и неофит не будет ждать развёрнутый задом на перёд список
Я просто имел в виду, что 1 цифра - это начало, а вторая - конец. Но это скорее я неверно выразился

10:10 - 10 cообщений, начиная с десятого
-10:5 - 5 сообщений, начиная с минус-десятого

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

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

> Только со временем тяжко нынче - я опять человек-отдел =)
То же самое =), даже написать сюда времени иногда нет.

> Честно говоря, даже то небольшое сообщение с сетью ulis мне не показалось ни полезным ни интересным. Вкупе с периодическими неконструктивными разборками, которые Рома устраивает (а я настолько слабая личность, что ведусь и вступаю в полемику), не вижу большого смысла гейтоваться с его сетью. Но чисто технически ничего сложного в этом нет и моя нода будет обрабатывать сообщения с любыми msgid.

Мне тоже кажется, что обсуждения про ["хоккей" и "какие идиоты сидят на очередном околоспортивном сайте"] никому не нужны кроме него самого; аналогично наваливает скептицизм. Но для начала попробовать стоит (а вдруг, вдруг? =) ), так что фильтр на msgid пока ослаблю.