й x/h.

Сделал фетчер, учитывающи

А где /x/features ?

Может их в виде /features.txt организовать? Всё равно это по сути статический текст…

Это всё делается в одной функции

shaos> Что значит усложнит? Валидацию входящего в любом случае надо делать - вот вместе с валидацией и делать конверсию если надо

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

Что значит усложнит? Валидацию входящего в любом случае надо делать - вот вместе с валидацией и делать конверсию если надо

Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html

Словарик будет отдельным документом.

Какие-либо ещё замечания и предложения будут?

PS: Перед окончательной публикацией дождусь реакции hugeping.

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

shaos> Ну можно написать, что принимаем любой текст, но сохраняем только с \n (и сервер считает хеш уже по сконверченному тексту)

Это усложнит логику сервера и, что важнее, замедлит обработку постов.

Проехали
Проехали

> Так получилось. Немного оборвался канал при отправке и клиент не понял, что сообщение принято.

Ну можно написать, что принимаем любой текст, но сохраняем только с \n (и сервер считает хеш уже по сконверченному тексту)

AL>> Всё ещё не считаю это задачей стандарта. Мы передаём текст. Любой. Хотя, если большинство согласится, что нам нужно это стандартизировать, соглашусь.
revoltech> А как же интероперабельность? Вот, допустим, человек решил написать клиента под старый Макинтош. Очень старый, ещё на процессоре архитектуры 68k, где ещё MacTCP отдельным пакетом шёл. Знаешь, какой на тех макосях тогда был стандартный символ перевода строки? Не LF и даже не CRLF, а именно CR. И как, будет тот клиент работать с существующими нодами, если стандарт не уточнит этот момент?

Принимается. Укажу конкретный символ тогда.

+++ Caesium/0.4 RC1

shaos> Сообщения раздваиваются
shaos> Сообщения раздваиваются

Где?
Где?

+++ Caesium/0.4 RC1

Сообщения раздваиваются
Сообщения раздваиваются

AL> Всё ещё не считаю это задачей стандарта. Мы передаём текст. Любой. Хотя, если большинство согласится, что нам нужно это стандартизировать, соглашусь.

А как же интероперабельность? Вот, допустим, человек решил написать клиента под старый Макинтош. Очень старый, ещё на процессоре архитектуры 68k, где ещё MacTCP отдельным пакетом шёл. Знаешь, какой на тех макосях тогда был стандартный символ перевода строки? Не LF и даже не CRLF, а именно CR. И как, будет тот клиент работать с существующими нодами, если стандарт не уточнит этот момент?

doesnm>>> Отличия от ii только в имени эх?
revoltech>> И в слайсах.
doesnm> Может я слепой, но по ссылке не нашел упоминания слайсов

2.3 /u/e/

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

doesnm>> Отличия от ii только в имени эх?
revoltech> И в слайсах.

Может я слепой, но по ссылке не нашел упоминания слайсов

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

AL>> Накинул приблизительный черновик стандарта.
AL>>
AL>> http://s.spline-online.ru/idec.html
AL>>
AL>> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
revoltech> Выглядит неплохо. Но несколько моментов:
revoltech> 1) было бы неплохо уточнить символ переноса строки;

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

revoltech> 2) было бы неплохо уточнить для непосвящённых, что такое аплинки и даунлинки;

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

revoltech> 3) в старом стандарте указано, что для постинга именно через GET /u/point поле tmsg должно быть закодировано не просто в Base64, а в Base64-urlsafe. В новом стандарте это требование убирается или как?

Безоговорочно принимается. Требование остаётся.

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

AL>> Накинул приблизительный черновик стандарта.
AL>> http://s.spline-online.ru/idec.html
AL>> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
doesnm> Отличия от ii только в имени эх? Просто на глаз по памяти ничего другого не заметил

Имена эх ничем не отличаются от ii-шных. Там ничем они не ограничивались фактически. Так что только слайсами отличается. Остальное шелуха :)

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

Прокинул на таверну ii://std.rein и ii://retro.talks

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

tuple>>> Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.
AL>> Ты так говоришь, как будто кто-то заставляет тебя подписываться или тянуть эти эхи к себе.
AL>> PS: А как в RSS-ридере обсудить с участниками сети что-то? :)
doesnm> Похоже от тебя пришло 2 одинаковых сообщения: ii://paG6r6FDOTURdMLwfObS и ii://AFI7XFZL9kmtNGAUieKP

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

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

doesnm> Отличия от ii только в имени эх?

И в слайсах.

AL> Накинул приблизительный черновик стандарта.
AL>
AL> http://s.spline-online.ru/idec.html
AL>
AL> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.

Выглядит неплохо. Но несколько моментов:

1) было бы неплохо уточнить символ переноса строки;
2) было бы неплохо уточнить для непосвящённых, что такое аплинки и даунлинки;
3) в старом стандарте указано, что для постинга именно через GET /u/point поле tmsg должно быть закодировано не просто в Base64, а в Base64-urlsafe. В новом стандарте это требование убирается или как?

AL> Накинул приблизительный черновик стандарта.
AL> http://s.spline-online.ru/idec.html
AL> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.

Отличия от ii только в имени эх? Просто на глаз по памяти ничего другого не заметил

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

tuple>> Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.
AL> Ты так говоришь, как будто кто-то заставляет тебя подписываться или тянуть эти эхи к себе.
AL> PS: А как в RSS-ридере обсудить с участниками сети что-то? :)

Похоже от тебя пришло 2 одинаковых сообщения: ii://paG6r6FDOTURdMLwfObS и ii://AFI7XFZL9kmtNGAUieKP

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

Накинул приблизительный черновик стандарта.

http://s.spline-online.ru/idec.html

Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.

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

tuple> Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.

Ты так говоришь, как будто кто-то заставляет тебя подписываться или тянуть эти эхи к себе.

PS: А как в RSS-ридере обсудить с участниками сети что-то? :)

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

tuple> Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.

Ты так говоришь, как будто кто-то заставляет тебя подписываться или тянуть эти эхи к себе.

PS: А как в RSS-ридере обсудить с участниками сети что-то? :)

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

> Для этого надо отвечать на сообщения там, а не в той теме про невидимые эхи.

Полуневдимые эхи :)

Я только вчера заметил, что пропустил букву в первом слове сабжа ;)

Полуневидимые имелось ввиду конечно же :)

Да, ботов тут дофига :)

idec.talks...........468

Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.