ahamai> Андрей, а что с rss-гейтом? Мёртв с 16 числа.

Умер.

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

ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1

Что это должно делать?

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

AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики
hugeping> Я тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть:
hugeping> 1) получили счётчики
hugeping> 2) нарисовали пагинатор
hugeping> 3) по мере "листания" пользователя - проходим сообщения слайсами
hugeping> Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.

Мысль интересная, но я бы за такие манипуляции со своей станцией карал :)

hugeping> P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....

Там они показывают фактическое количество сообщений. То есть могут иметь отрицательный рост :)

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

>> ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1
>> Что это должно делать?
shaos> Возвращать хеши эх вместо дескрипшина:
shaos> ====
shaos> idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
shaos> blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
shaos> retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
shaos> bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
shaos> lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
shaos> ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
shaos> lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
shaos> linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz
shaos> ====

Какую проблему это решает?

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

AL>> Потому что документация описывает IDEC.
revoltech> Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

И даже писал.

revoltech> Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:
>> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.
revoltech> И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

Бывает.

revoltech> То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.

Зачем?

revoltech> Я вот вместе с кодобазой tii начал вести свой ii-doc.txt, где описываю только реализованные в tii части протокола. И с пометкой IDEC extension у меня там только GET /x/features и один из вариантов /u/e, который со слайсами.

Молодец.

AL>> Слишком много оверхеда.
revoltech> Слишком много сарказма. Если уж позиционируем протокол как альтернативу щитвебу и если уж спецификация не обязывает именно к HTTP(S)-транспорту (опять гитхаб процитировать?), то вполне логично принимать и предложения по более легковесным протоколам вместо упора в жирный HTTP(S).

Ну то, как Вы позиционируете протокол, мы узнали только что. Сидим вот, думаем что дальше с этим делать.

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

ahamai> что с лор.опеннетом делать будем?

Чинить. Займусь сегодня.

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

tuple>> Почему жирный-то? Почти натуральный plaintext. Куда меньше?
revoltech> Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.
revoltech> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900
revoltech> Ничего, кроме нетката, телнета или подобного, в основе не требуется.
revoltech> Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:
revoltech> cat <<EOF | nc station.domain 1915
revoltech> /u/point
revoltech> [auth_string]
revoltech> [base64_message]
revoltech> .
revoltech> EOF
revoltech> Вот тут уж действительно меньше некуда.

Ну так пиши транспорт какой тебе больше нравится. Стандарт не завязан на HTTP как таковой. Был опыт обмена и по FTP. Просто HTTP всех устраивает, так как дёшево и просто с точки зрения использования и уже так сложилось.

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

shaos>>> Меньше это Gopher или Nex овер телнет :)
revoltech>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm> Го дропнем base64

Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.

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

ahamai> Думаю о создании станции lor2ii, которая будет медленно и печально собирать сообщения с текущих тем лора.
ahamai> Без веб интерфейса, либо с веб интерфейсом только для пойнтов.
ahamai> При этом пойнты могут комментировать эти сообщения и они будут доступны другим пойнтам. Получится этакий OverLor.
ahamai> Сообщения с лора тэгировать чем-то типо lorlink/урл-на-сообщение.
ahamai> Вернуть http-клиента и ориентировать на всё это.
ahamai> Кому-нибудь такое интересно?

А чем текущая эха не устраивает? Зачем аж отдельная станция для отдельной эхи?

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

shaos>> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)
revoltech> Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.

Мы и определились и отказались от максимализма.

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

ahamai>> а вообще, у нас сейчас фанаты технологии, но нет фанатов распределённости и локального хранения.
revoltech> Есть. Поэтому все подвижки в сторону «выкачивать не всё и не отовсюду» предлагаю отметать, как вредоносные.
revoltech> В идеале — дайте мне возможность скачать все эхи одним файлом, а дальше уж разберусь локально, что с этим делать.

Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.

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

ahamai> И я не про маинтайнеров писал, а про то, что будет если просто задним числом вычистят копирайты из кода и скажут "так и было".

Легко доказать, что так не было. Это уже нарушение лицензии, так что их свои же могут нагнуть.

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

ahamai>> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то
revoltech> В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.

Почему?

revoltech> * длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);

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

revoltech> * на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.

Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.

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

Починил сабж.

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

shaos> Проблему большого траффика когда тянется всё подряд без оглядки

Эту проблему прекрасно решают слайсы. Посмотри на трафик от Петра. Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?

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

shaos>> тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую
hugeping> Собственно, для этого msgid и нужен. Если ты хочешь на него нагрузить что-то ещё "для красоты", то да, не будет работать редактирование, как минимум. Я понял, что у нас тут разные стремления. Но может быть лучше сделать базовую технологию обмена, а подлинность целостность - это отдельно? Без возможности редактирования сообщений мне ii-go бесполезен. Я ведь использую его для создания заметок. У меня даже резюме лежит на нём. :)

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

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

>> shaos> Проблему большого траффика когда тянется всё подряд без оглядки
>> Эту проблему прекрасно решают слайсы.
shaos> Ну будут решать ещё лучше, когда необходимость дёргания будет решаться не по количеству сообщений в эхе, а по хешу т.к. например в ii-php количество сообщений это реальное количество сообщений в эхе и в /list.txt, и в /x/c (т.е. оно может не только расти, но и уменьшатся, и даже оставаться неизменным когда убавилось столько же сообщений сколько и добавилось, но этого никто не заметил т.к. сравнивают номера).

Для слайсов количество вообще не обязательно.

>> Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?
shaos> Обычный /list.txt останется как был, а для хешей я пока делаю на выбор:
shaos> /list.txt?h=1
shaos> /listhsh.txt
shaos> и по аналогии с /x/c будет /x/h но вместо количества сообщений там будут хеши

А какой смысл в этом многообразии?

+++ Caesium/0.4 RC1

AL>> Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.
revoltech> Внезапно, я сам в селе. Интернет спутниковый.

Это что-то на богатом.

AL>> Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.
revoltech> Сделаю. Клиент tii (а конкретнее — компонент tiifetch), собственно, уже поддерживает выкачивание по гоферу, нексу, спартану и джемини. Не на чем только это всё потестить покамест.

Твой клиент не работает с твоей нодой?

AL>> Почему?
revoltech> А кто её передаст, точку эту?

Твоя нода на новом транспорте?

AL>> Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.
revoltech> Вот для первого выкачивания такая опция не помешала бы. Иначе ему придётся качать те же несколько сотен мегабайт, но маленькими фрагментами.

Что повышает надёжность передачи на нестабильном канале.

AL>> Мы и определились и отказались от максимализма.
revoltech> Вместе с минимализмом.

Всё так. От крайностей одни неприятности.

+++ Caesium/0.4 RC1

doesnm>>> Го дропнем base64
AL>> Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.
doesnm> Поддерживаю

FTN у нас уже есть.

+++ Caesium/0.4 RC1

>> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов.
shaos> И каждый раз приходит суровый Andrew Lobanov и ставит фантазёров на место :)

Да я что? Я ничего. Так, погулять вышел. Просто надо сильно всех загонять в рамки и часть узлов просто отвалится.

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

shaos> дык у него ещё нету ноды - тока клиент :)

Вот и повод написать ноду :)

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

AL>> FTN у нас уже есть.
doesnm> Сделать гейт в FTN

Смысла нет :)

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

>> Для слайсов количество вообще не обязательно.
shaos> т.е. ты предлагаешь каждый раз дёргать каждую эху с параметрами -1:1 чисто на всякий случай? ;)

Да. Не вижу проблемы. Разве что подключения платные и их приходится экономить :)

>> А какой смысл в этом многообразии?
shaos> эдакий A/B тест - кто что больше будет использовать, то прилипшим к стене и останется :)

Ну тоже вариант. Но на нашей выборке не сработает, скорее всего. Делай как удобнее будет тебе и всего делов :)

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

AL>> Твой клиент не работает с твоей нодой?
revoltech> Моей ноды ещё не существует.

Повод написать :)

AL>> Что повышает надёжность передачи на нестабильном канале.
revoltech> Каким образом, если проверка целостности по msgid, как мы выяснили, идёт лесом, а проверка целостности самого списка в эхе сейчас вообще отсутствует?
revoltech> Ну то есть давай смоделируем ситуацию — обрыв соединения при фетче эхи. Этот обрыв может произойти во время:
revoltech> 1) скачивания списка айдишников в эхе (GET /u/e),
revoltech> 2) скачивания бандла (GET /u/m).
revoltech> В случае номер 1, если обрыв произошёл до последнего известного нам айдишника, мы не знаем, что там между ними (последним известным нам и тем, где произошёл обрыв), поэтому всё равно придётся запрашивать тот же список заново, независимо от размера.
revoltech> В случае номер 2, который на слабом канале критичнее, мы сравниваем список полученных сообщений со списком запрошенных и при несоответствии оных просто перекачиваем с последнего полученного (т.к. его тело могло быть выкачано не полностью). Изначальный размер бандла при этом значения также не имеет.

При этом, если вернулось не 200, то всё идёт лесом до следующего раза.

revoltech> И это ещё с допущением, что само соединение установлено успешно. А чем нестабильнее канал, тем дольше устанавливается соединение. И накладные расходы на кучу мелких запросов в этом случае ещё сильнее влияют.

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

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

tuple> IDEC протокол нужен только для обсуждения IDEC-реализаций.

Можем обсуждать что угодно. Но все предпочитают обсуждать технологию :)

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

tuple>> IDEC протокол нужен только для обсуждения IDEC-реализаций.
revoltech> Sad but true. Хотя мне, наверное, было бы достаточно корректно работающего ii. Просто по ходу дела выяснилось, что это ближе к мифу или оксюморону.

IDEC на 100% совместим с ii-0.3. Пользуйся и радуйся жизни.

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

hugeping>> Ну, хочется видеть idec другим -- никто не мешает разрабатывать свои варианты...
tuple> Жаль при этом происходит дробление сообществ на всё более мелкие части...

Потому что все хотят менять стандарт или обвешивать его расширениями вместо того, чтобы просто пользоваться :)

Девять лет жили с текущим стандартом и тут все занемогли с него.

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

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

hugeping>> Драматизировать тоже не стоит.
revoltech> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?
revoltech> * Раз GET /list.txt всегда был в ii, надо его описать в базе, а не в расширениях.

Вообще не будет расширений. Будет один стандарт и всё. Расширения на совести людей, их реализующих останутся.

revoltech> * Раз айдишники в виде волшебного шопопало до сих пор проскакивают, надо указать, что алгоритм их генерации рекомендован. И указать правила замены на A-z, которые все ноды между собой понимали бы.

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

revoltech> * Раз счётчики де-факто могут убывать, надо убрать ту приписку «Важно: параметр неубывающий».

Это не важно. В новом стандарте счётчиков не будет.

revoltech> Ну и так далее. В общем, привести теоретическую базу к тому, как оно всё на самом деле функционирует. Чтобы новые авторы клиентов (а тем более серверов) не путались в этих трёх соснах как минимум.

Ну новый стандарт будет компактный и простой.

revoltech> Я могу выложить свою (англоязычную) доку где-то здесь. Либо в english.talks, либо в какуюто новую эху. Там сейчас базовый ii без расширений по факту. Есть желание привлечь нексовских, гоферистов, джеминистов и прочих активистов смолнета к этой теме, но для начала неплохо было бы довести документацию до удобоваримого вида без разночтений.

Жди и всё будет. У меня сейчас не очень простой период в жизни в плане свободного времени.

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

revoltech> А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта. А по факту мы видим не то, что там написано.

А по факту это всё ни на что не влияет и работает без проблем.

hugeping>> С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.
revoltech> Как и многое другое оттуда же.

Вот ты дотошный без особого смысла :)

hugeping>> А что ещё? Ну, переводы строк?
revoltech> Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.

Переводы строк могут быть какими угодно. Символ возврата каретки ни на что не влияет.

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

revoltech>> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?
tuple> В организации значатся двое: difrex (у него была станция, сейчас её нет, давно не видно), btimofeev пару недель назад с ним общались в сети. Зовём его, пусть делает новый репозиторий для Github Pages, туда можно напосылать PR'ов с исправлениями. Но сначала просто полностью скопировать https://github.com/idec-net/new-docs , затем переделать его под Jekyll (чтобы github pages заработал), а только затем посылать всякие исправления и улучшения.

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

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

revoltech>> В extensions.md: написано: «Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii.» — и там перечислен в том числе /list.txt. Это читается так, как будто IDEC от ii отличается в том числе /list.txt, т.е. в ii его не было.
hugeping> В ii не было просто самого механизма расширений. В любом случае, смысл менять стандарт я не вижу. Иначе придётся требовать наличия list.txt как обязательного компонента.

Придётся. Раз уж мы тут шатаем то, что есть, то пошатаем и это. Бойтесь :)

revoltech>> А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта.
hugeping> id создаётся один раз в момент создания сообщения, для обмена нет необходимости его где-то пересчитывать. Главное, уникальность. Вероятность коллизии крайне мала, при условии что id считается какой-то хорошей хеш функцией. Хотя, думаю, можно в принципе и тупо рандом брать, думаю на наш век этого точно хватит.

Сейчас всё нормально. Так и оставим по сути.

revoltech>> Как и многое другое оттуда же.
hugeping> Что именно? x/c - да. msgid - нет, нет такого требования. Хеши и не должны совпадать. Но ты пишешь "многое другое". Где пруфы?

Голословность как дух времени :)

hugeping> Мне кажется ты совсем не читаешь то, что я тебе пишу. Прекращаю это бессмысленное занятие. :)
revoltech>> Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.
hugeping> На самом деле с переводами тоже не все просто. Я когда написал фильтр получил ещё несколько сообщений с \r где-то в теле. Я стал их резать при записи в БД. Кстати, ещё один источник того, что хеш может отличаться. В общем, idec и ii не требуют совпадений при пересчёте хеша. Пересчёт вообще не должен нигде проводиться.

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

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

AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.
hugeping> А ты знаешь, подумал... Вообще, мне нравится. Без x/c можно жить, тем более если list.txt в базе будет.

В list.txt счётчик может убывать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. В новом стандарте это требование убирается или как?

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

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

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

2.3 /u/e/

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

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

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

+++ Caesium/0.4 RC1

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

Где?
Где?

+++ Caesium/0.4 RC1

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

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

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

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

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

shaos> А где /x/features ?

А зачем она, если не будет расширений? Расширения были ошибкой.

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

Можно что угодно вертеть, но в стандарте этому не место.

+++ Caesium/0.4 RC1

>> Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.
ahamai> проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает. если бы это был запрос /u/e/ea/ea/ea?s=-100:100, тогда бы посторонние ноды это проигнорировали

В тмени эхи не может быть двоеточия. Так что не выглядит. Ну и просто будет пустой индекс невалидной эхи в ответе. Это ничему не навредит.

+++ Caesium/0.4 RC1

ahamai> а почему оно /u/e а не /x/e какое-нибудь. надо или делать ?s=X:X или /x/e, потому что запрос один, а реакции разные

Делай как угодно. Стандарт есть стандарт. Большинство его соблюдает вполне успешно даже сейчас.

+++ Caesium/0.4 RC1

shaos> Наверное старая нода должна ошибку вернуть если в запросе непонятное буквосочетание попалось, не?

Надо на таверне проверить. Старше сейчас, вроде, ничего нет.

+++ Caesium/0.4 RC1

ahamai> Речь о том, как на это реагирует референсная реализация. Хреново :)

А у нас пока нет референсной реализации. Стало быть никак не отреагирует.

+++ Caesium/0.4 RC1

shaos> А существующие реализации в сети не 100% IDEC уже? ;)

У Ромы никогда не было IDEC-ноды. Блин. Научить фетчер работать без слайсов с некоторыми аплинками - задача на 2-3 лишние строки кода. Проблема высосана из пальца.

Если бы IDEC был ii, то он бы назывался ii.

+++ Caesium/0.4 RC1