hugeping> Да, я там сделал попытку предложить что-то (как мысленный эксперимент): ii://sZbskcy7huzEVJlsSDIF

hugeping> Вроде в таком варианте новые версии сообщения будут распространяться.

То-есть, основные мысли:
1) если видим что что-то на станции в этой эхе поменялось - всегда делаем полный фетч (адаптивный фетч в топку)
2) во время фетча учитываем не только id, но и ревизию сообщения. Всё это для простоты может быть частью msgid (но может и не быть)

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

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

shaos> лучше версионность делать иными средствами имхо - поверх и сбоку

> т.к. оно будет нужно только для очень особенного типа сообщений

hugeping> JOHemYNZRC8Uo9QwAYQU:1

hugeping>> JOHemYNZRC8Uo9QwAYQU:1

hugeping> Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.

Гм. На практике, редактирование сообщения - добавление новой записи в бд. Так что тут не все так просто.

hugeping>>> JOHemYNZRC8Uo9QwAYQU:1

hugeping>> Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.

hugeping> Гм. На практике, редактирование сообщения - добавление новой записи в бд. Так что тут не все так просто.

Да нет, вроде нормально... Редактирование сообщения - это выпуск msgid с новым полем rev. Это на усмотрение ноды как именно отразить это в бд. В ii-go это дописывание новой инфы которая "перекрывает" старую. В sql это может быть тупо запись в бд. Требовать чтобы запись добавилась в конец запроса u/e наверное нецелесообразно.

> Понимаешь, у всех у нас своё "особенное" понимание. Я считаю что ii следует понимать просто как распространение текстовых сообщений. Что ИМЕННО в этих текстовых сообщениях - не наше дело. Кто-то считает, что это "мессенджер", кто-то - форум, а кто-то в блогах пишет....

shaos> Ну вот поэтому все редакции "особых" сообщений должны идти как отдельные записи в списке хешей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+++ Caesium/0.4 RC1

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

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

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