hugeping> Драматизировать тоже не стоит.

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

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

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

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

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

shaos> а почему бы и не добавлять также как в хттп?
shaos>
shaos> /u/point/pauth/tmsg
shaos>
shaos> \n и забираем ответ
shaos>
shaos> или там ограничение на длину запроса?...

> ну и /x/h/echo.1/echo.2 по аналогии с /x/c/echo.1/echo.2 сдедал, например
> ====
> > curl https://sprinternet.io/iii/x/h/retro.talks/idec.talks
> retro.talks:mWbHlTgoAaE1IaEoubCR
> idec.talks:4dBW6db3TdOmYzbdZAg5
> ====

retro.talks:mWbHlTgoAaE1IaEoubCR
idec.talks:KCAVqaCJCot0ByQVlWg5

> curl https://sprinternet.io/iii/x/h/retro.talks/idec.talks
retro.talks:mWbHlTgoAaE1IaEoubCR
idec.talks:4dBW6db3TdOmYzbdZAg5

hugeping>>> JOHemYNZRC8Uo9QwAYQU:1

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

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

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

hugeping>> JOHemYNZRC8Uo9QwAYQU:1

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

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

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

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

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

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

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

hugeping> JOHemYNZRC8Uo9QwAYQU:1

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

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

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

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

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

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

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

> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов.

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

+++ Caesium/0.4 RC1

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

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

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

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

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

+++ Caesium/0.4 RC1

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