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

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

Так же сделать проект с описанием стандарта в каком-нибудь 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 уже было такое предложение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Вот я тоже думаю ... Но без переездов бы она сильно упростила жизнь.

unixtime смущает. Это что получается: сервер должен распарсить все N тысяч сообщений на время?

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

>> Вот я тоже думаю ... Но без переездов бы она сильно упростила жизнь.
>unixtime смущает. Это что получается: сервер должен распарсить все N тысяч сообщений на время?

Только если нода хранит сообщения в файликах, а не в базе.

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

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

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