В связи с "родовыми травмами 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.

> Какой толк в регулируемой длинне msgid?
Просто ради совместимости. А то тут по 100500 стандартов всякие делают, что потом гейтоваться трудно. Мне, если честно, так и хочется 20 оставить.

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

>> Хоть убей не помню о чём речь. Напомни пожалуйста.
>/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? Так будет логичнее запись запроса и неофит не будет ждать развёрнутый задом на перёд список (как я ненавижу это в рескане фидошных эх) =)

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

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

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

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

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

В случае получения ошибочных параметров (например -5:10), нода возвращает полный список сообщений, но это можно переделать при желании, изменив всего одну строку кода.

О, отлично.
ii-php пока нескоро делать буду из-за резкого недостатка свободного времени, но обязательно реализую.

Может, теперь наконец-то стоит публично сообщить о нашем решении в pipe.2032/ii.14?

>Может, теперь наконец-то стоит публично сообщить о нашем решении в pipe.2032/ii.14?
Я бы ещё клиент хоть какой-нить написал, если ты не возражаешь.

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

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

Оглядываясь на Fido, есть идея сделать отдельный интерфейс в цезии и скрипт в iitxt для забора нестандартной выборки и просто добавить эти сообщения в существующую базу в конец. Пожалуй, так и сделаю, но готов услышать любые предложения по теме.

ЗЫЖ Не сегодня, так завтра, наверное, напишу iitxtng с учётом уже сделанного и надуманного.

ЗЗЫЖ Просто показывать по факту нерабочую вещь не хочется, а хотя бы такую ноду, какая есть и iitxtng уже можно и людям показать =)

Для осмысленных выборок из базы ноды клиенту необходимо знать сколько сообщений в эхоконференции имеется. Для этого я реализовал расширение в виде схемы /x/count. Работает это так: запрашиваем у ноды /x/count/ii.14 и получаем количество сообщений в эхе ii.14.

Нововведение уже в репозитории.

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

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

> Оглядываясь на Fido, есть идея сделать отдельный интерфейс в цезии и скрипт в iitxt для забора нестандартной выборки и просто добавить эти сообщения в существующую базу в конец.
Добавить параметры командной строки к фетчеру iitxt, и дело с концом.

Мне кажется, что /x/count не нужен, потому что новый интерфейс с минусами и лимитами, который я предложил, убирает в нём необходимость.
Для начала клиент забирает последние n сообщений, затем если среди них все новые (либо первое из полученных новое, что проще проверить), то он забирает -2n:n, -3n:n и так далее в цикле.

Кстати, /x/t в php-ноде работает точно так же, как /x/count =)

>Мне кажется, что /x/count не нужен, потому что новый интерфейс с минусами и лимитами, который я предложил, убирает в нём необходимость.
>Для начала клиент забирает последние n сообщений, затем если среди них все новые (либо первое из полученных новое, что проще проверить), то он забирает -2n:n, -3n:n и так далее в цикле.
Если, например, я знаю название эхи, но не забираю /list.txt, то для построения хитрого запроса может понадобиться знать число сообщений. К тому же запрос count удобнее и проще парсинга list.txt.

>Кстати, /x/t в php-ноде работает точно так же, как /x/count =)
Блин. Ну переделать count на t не долго.

> для построения хитрого запроса
> хитрого
Ой, не заметил этого слова =) Теперь все претензии снимаются, получать количество в таком случае вполне нормально.

> Блин. Ну переделать count на t не долго.
Я просто поставлю, чтобы они одинаковыми были, если что.

>> Блин. Ну переделать count на t не долго.
>Я просто поставлю, чтобы они одинаковыми были, если что.
Лучше оставить один вариант, ИМХО. Ни к чему дублировать схемы -- только путаницу разводить.

Дело тут в том, что /x/t - это более расширенная схема. В стандарте говорится, что она должна выдавать "версию базы", которая может являться абсолютно любым числом, но увеличивающимся со временем. Я реализовал /x/t на основе количества сообщений. В принципе, /x/t нигде кроме Qt клиента не реализован, так что можно от него избавиться и переименовать в /x/count или /x/c

Избавляемся от /x/t в пользу /x/count?

Предлагаю также /x/count переименовать в /x/c

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

Тогда запрос /u/e/20/30 можно истолковать двояко: выбрать эхи 20 и 30, либо выбрать 30 первых сообщений из эхи 20.

Обходное решение - сделать двоеточие обязательным. Тогда запрос для выборки первых 10 сообщений будет выглядеть, как /u/e/echo/0:10
Для последних -10:10

// ветку features возрождаю, после уточнения алгоритма точно обновлю API

Изменения в ветке features php-ноды:
* убрал обязательные постфиксы
* расширил /u/e/ по обновлённой схеме с учётом предыдущего сообщения

Теперь нам надо думать, как отличать эхи от сообщений в бандле (они ж без постфиксов теперь). O_o

>Избавляемся от /x/t в пользу /x/count?
Всё таки это разные схемы. С другой стороны, кто у нас поддерживает /x/t?

>Предлагаю также /x/count переименовать в /x/c
Почему бы и нет. Это лучше соответствует общей стилистике именования.

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

>Обходное решение - сделать двоеточие обязательным. Тогда запрос для выборки первых 10 сообщений будет выглядеть, как /u/e/echo/0:10
>Для последних -10:10
Как вариант, кстати, да.

> Всё таки это разные схемы. С другой стороны, кто у нас поддерживает /x/t?
Только мой Qt-клиент. Мне переименовать /x/t в /x/c - на раз-два. А алгоритм работы менять даже не придётся.

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

> Как вариант, кстати, да.
Так и поступил в ветке features.

И ещё (цитирую самого себя):

> Теперь нам надо думать, как отличать эхи от сообщений в бандле (они ж без постфиксов теперь). O_o

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

>> Теперь нам надо думать, как отличать эхи от сообщений в бандле (они ж без постфиксов теперь). O_o
>Раньше проверка всегда шла по точке. Есть точка в названии - значит оно является эхой. Настоящая ситуация полностью ломает все фетчеры, и это реальная проблема.
Не вижу большой беды. Разве что ii-ссылки придётся переделать, а остальное нормально и так должно работать. Пока нет времени, но при случае попробую реализовать безточечный вариант. А вот имена эх в виде чисел это как-то излишне и я бы блокировал создание таких эх на ноде. Но тут думать надо, а я на вскидку говорю. Написать тесты, посмотреть какую логику взаимодействия можно реализовать и насколько она останется простой. Плюс надо сохранить совместимость как со стороны клиентов, так и со стороны ноды. В общем, я не готов сейчас писать что-либо адекватное по теме.

Проект iing у меня не заброшен, но пока приостановлен.

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

Ладно, объясню конкретно:

делаем /u/e/test.15/myechoarea/ii.test.15
выводит

test.15
msgid
msgid
msgid
msgid
msgid
myechoarea
msgid
msgid
ii.test.15
msgid
msgid
msgid

Как фетчер поймёт, что myechoarea - это эха, а не сообщение? А если мы назовём эху 20-символьным именем, то и человеческим глазом спутать можно.

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

> Плюс надо сохранить совместимость как со стороны клиентов, так и со стороны ноды.
----

> А вот имена эх в виде чисел это как-то излишне и я бы блокировал создание таких эх на ноде. Но тут думать надо, а я на вскидку говорю.

Можно сделать регулярку, которая требует как минимум одну букву в названии эхи. Хотя это не принципиально. Надо бы спросить остальных.

>Ладно, объясню конкретно:

>делаем /u/e/test.15/myechoarea/ii.test.15
>выводит

>====
>test.15
>msgid
>msgid
>msgid
>msgid
>msgid
>myechoarea
>msgid
>msgid
>ii.test.15
>msgid
>msgid
>msgid
>====

>Как фетчер поймёт, что myechoarea - это эха, а не сообщение? А если мы назовём эху 20-символьным именем, то и человеческим глазом спутать можно.

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

Ну тут у нас всего два варианта: либо схема /u/e будет принимать только один аргумент (есть ли у нас клиенты, которые вобше несколько аргументов ей отдают?) или ломаем совместимость с помощью того же двоеточия. Надо дифрекса звать. Я несколько дней думал, но однозначного ответа придумать не смог. С одной стороны двоеточие будет хорошим шагом, но тогда точно не останется совместимости и придётся пилить поддержку нового стандарта в своих клиентах (мне не тяжело, но как на нас посмотрят остальные? =)

>> А вот имена эх в виде чисел это как-то излишне и я бы блокировал создание таких эх на ноде. Но тут думать надо, а я на вскидку говорю.

>Можно сделать регулярку, которая требует как минимум одну букву в названии эхи. Хотя это не принципиально. Надо бы спросить остальных.

Можно много чего сделать. Наверное или Дифрекса надо звать или вобще эху уже делать открытой и написать объявлние в ii.14.

> (есть ли у нас клиенты, которые вобше несколько аргументов ей отдают?)
webfetch.php, Qt-клиент + все бывшие клиенты Ромы, включая iipython 0.3 и 51talk.

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

И да, насчёт множественных аргументов в /u/e

У меня в подписках:
на ii-net.tk 18 эх
у Андрея 2 эхи
на irk39.tk 7 эх
и на localhost 1 эха

В текущем варианте для получения полного списка сообщений клиент делает 4 запроса (и опциональный /x/t вдобавок).
Если перейти на единичный аргумент, то их будет 28, то есть в 7 раз больше.

Так что со своей стороны говорю, что вариант превращения /u/e в /e выглядит полным ужасом =)

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

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

Так же сделать проект с описанием стандарта в каком-нибудь asciidoc(он прекрасно компилируется в pdf). То, что сейчас у нас есть -- это разрозненные куски непонятно где. Лирическое описание так вообще ни о чем.

ЗЫ: Первый фичреквест(я все же клиент пилю, а не сервер): хочу получать последние сообщения от msgid типа

curl http://node/m/e/t/h/o/d/echo.15/MsGiD
{
  [
    'msgid': unixtime,
    'msgid2': unixtime 
  ]
}

Можно и не в JSON кончено, это так, для наглядности. Почему по msgid, а не по unixtimе? ИД уникальный, а за одну секунду могли запостить несколько сообщений.

ЗЗЫ: Запилил(на самом деле не до конца) ноду, которая все отдает в JSON и реквесты принимает в JSON :D

>хочу получать последние сообщения от msgid типа
Ага не прочитал все сообщения. В ii://IUy9wONFw2EGk4Y5XHbC уже было такое предложение.

Новые коммиты в сабже. Изменения:

* Добавлено полностью рабочее расширение /x/file (со всеми деталями, что обсуждали в ii.14)
* Удалён /x/t, вместо него теперь /x/c (ещё читаемость кода улучшил в той функции)

А что ты думаешь насчёт вот этого сообщения? ii://Vt3hbxrZTExHwhGHOQFn

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

Для начала нам надо определить, какая нода из тех +-9000 является эталонной =)
Но идея хорошая.

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

Про asciidoc: если просто скопировать содержимое документации, которое у нас уже есть, то без проблем. Если изменять, то пока не знаю, как будет лучше.

>А что ты думаешь насчёт вот этого сообщения? ii://Vt3hbxrZTExHwhGHOQFn
Ящитаю, что без префиксов жизнь плоха. Их не обязательно делать цифровыми, но одна точка в названии эхи быть должна.

И длину ID не надо менять. Есть 20 символов и пускай будет 20 символов. Если надо гейтить другую сеть, то решать это надо на стороне ноды, а не стандарта. Т.е. плагинами там или еще как-то.

А если я хочу клиентом ii забирать сообщения ii, то я ожидаю, что msgid будет длиной в 20 символов.

ЗЫ: имя notii никем не занято?

> Ящитаю, что без префиксов жизнь плоха. Их не обязательно делать цифровыми, но одна точка в названии эхи быть должна.
Можно и без постфиксов жить, если реализовать нужные стандарты на ноде. Идея с одной точкой вполне жизнеспособна, так как не будет ломать совместимость.

> И длину ID не надо менять. Есть 20 символов и пускай будет 20 символов. Если надо гейтить другую сеть, то решать это надо на стороне ноды, а не стандарта. Т.е. плагинами там или еще как-то.
Лично мне тоже хочется оставить ровно 20. Хотя проверок на длину я даже на ноде не реализовывал. Нода смотрит только алфавит base64 в msgid.

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

> ЗЫ: имя notii никем не занято?
Погуглил и пояндексил. Никем не занято, за исключением чьих-то никнеймов и какого-то корейского сайта.

Закинул на ноду вот такой скрипт http://ii-net.tk//ii/ii2rss.php

Вечером приду домой и, может быть, сделаю коммит.

>Новые коммиты в сабже. Изменения:
>* Добавлено полностью рабочее расширение /x/file (со всеми деталями, что обсуждали в ii.14)

Я тут глянул. Есть предложение на общее обсуждение.

ii хоть и завязан плотно на http, но чисто теоретически является паразитической сетью, которая должна работать поверх произвольного протокола. Может стоит реализовать файлы с base64-кодированием, а не просто по http отдавать файл?

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

Что думаете?

PS: Это просто "набрасывание" идей. Пока без детального изучения ситуации и конкретных экспериментов.

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

Если речь о текущем стандарте, то эталонная нода это нода, которую Рома писал. А если о том, что обсуждаем, то лучше сперва таки стандарт соглосовать и оформить.

>ЗЫ: Первый фичреквест(я все же клиент пилю, а не сервер): хочу получать последние сообщения от msgid типа
>====
>curl http://node/m/e/t/h/o/d/echo.15/MsGiD
>{
> [
> 'msgid': unixtime,
> 'msgid2': unixtime
> ]
>}
>====

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

>ЗЗЫ: Запилил(на самом деле не до конца) ноду, которая все отдает в JSON и реквесты принимает в JSON :D

Какой-то интересный у вас ii =)

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

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

Ещё вот надо что-то делать с сабжем, ИМХО. У нас цитаты совершенно не указывают на то, кто их писал. Что мне нравится в Fido, там принято писать первые буквы имени, потом знак > и рисовать им отступ в один пробел.

То есть если цитируют меня, то выглядит это примерно так:

AL>Вот я тут о цитировании задумался.

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

И да. Меня опять несёт в ломание совместимости, но я упорно продолжаю "накидывать" идеи.

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

Паразитичность сети это очень здорово. Я из этого исхожу. Конечно, это может показаться странным, но кто знает куда придут технологии, а ii иметь хочется независимо от них.

> Конечно, это может показаться странным, но кто знает куда придут технологии, а ii иметь хочется независимо от них.
Тогда, если что, буду отдавать файлы в base64. Всё равно скачивать их можно только с помощью authstr, так что спамеры не пройдут.

AL>Вот я тут о цитировании задумался.
А где пробел? =)

VF> Может, вот так, с пробелом?

> Ещё вот надо что-то делать с сабжем, ИМХО. У нас цитаты совершенно не указывают на то, кто их писал. Что мне нравится в Fido, там принято писать первые буквы имени, потом знак > и рисовать им отступ в один пробел.

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