# idec
Andrew Lobanov(tavern,1) — All
2019-03-03 17:00:54


Надо уже выкидывать всё к чертям из стандарта. Реально полезным оказался только расширенный u/e. Остальное никому не впилось и все старательно не поддерживают эти фичи. Аттачи или изуродуем и раздуем, что сразу сделает их не лучше фэх, или не реализуем вовсе. Так что брошу я это дело. Файлы можно и в ТГ кинуть кому надо.

Секта просрана. Люди боятся людей даже в таком маленьком обществе.

# Re: idec
Difrex(dynamic,1) — Andrew Lobanov
2019-03-03 17:45:56


> Реально полезным оказался только расширенный u/e.
x/c еще все используют. И u/m.

Зря ты так.
Я, например, думаю, что xdata на конце достаточно. Но должен быть еще один запрос, чтобы узнать, что там в данных. Например, я не хочу качать какие-то непонятные elf если они вдруг будут.
Я на самом деле за то, чтобы один пост - одно вложение, да и все.
И уж точно не как filename:base64data отдавать контент.

# Re: idec
Andrew Lobanov(tavern,1) — Difrex
2019-03-03 18:14:52


>> Реально полезным оказался только расширенный u/e.
Difrex> x/c еще все используют. И u/m.

Ну да. x/c ещё так как без него расширенный u/e бесполезен. u/m ничем у нас от ii не отличается.

Difrex> Зря ты так.
Difrex> Я, например, думаю, что xdata на конце достаточно. Но должен быть еще один запрос, чтобы узнать, что там в данных. Например, я не хочу качать какие-то непонятные elf если они вдруг будут.
Difrex> Я на самом деле за то, чтобы один пост - одно вложение, да и все.
Difrex> И уж точно не как filename:base64data отдавать контент.

Это всё слишком много. Проще выкинуть, чем делать. Кому надо столько запросов да на каждое сообщение?

Давай просто накидаем что и как должно быть и посмотрим насколько оно будет юзабельно. Пока видится кривым решением или решением с обязательным скачиванием (тут я не вижу проблемы).

# Re: idec
Difrex(dynamic,1) — Andrew Lobanov
2019-03-03 18:34:30


> Кому надо столько запросов да на каждое сообщение?
Не на каждое, а на то, которое с тегом ^_^

> Давай просто накидаем что и как должно быть и посмотрим насколько оно будет юзабельно
Так давай! Пили PoC :)

# Re: idec
Difrex(dynamic,1) — Difrex
2019-03-03 18:36:25


Я примерно представляю уже как впилить реализацию у себя в ноде, только сначала
подожду твоей.

Этож у нас МЕМАСИКИ появятся :).

# Re: idec
Andrew Lobanov(tavern,1) — Difrex
2019-03-03 18:58:56


>> Кому надо столько запросов да на каждое сообщение?
Difrex> Не на каждое, а на то, которое с тегом ^_^

Ну это да, но всё равно чёт стрёмно.

>> Давай просто накидаем что и как должно быть и посмотрим насколько оно будет юзабельно
Difrex> Так давай! Пили PoC :)

Не. Мою идею уже разгромили все, кому не лень. Подожду когда предложат чего получше =)

# Re: idec
Difrex(dynamic,1) — Andrew Lobanov
2019-03-03 18:49:25


> решением с обязательным скачиванием (тут я не вижу проблемы)

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

# Re: idec
Andrew Lobanov(tavern,1) — Difrex
2019-03-03 19:04:25


>> решением с обязательным скачиванием (тут я не вижу проблемы)
Difrex> Подумал над этим - да, наверное действительно проблемы нет. Нужно колличество байт только писать. Это не сложно, т.к. нода это знать должна при приеме данных.

Ну вот. Можно что-то типа тега

xdata/:

заюзать и действительно ограничить на один файл на сообщение.

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

# Re: idec
Peter(syscall,1) — Andrew Lobanov
2019-03-03 19:10:57


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

Это дело пользователей, а не ноды. В этом и была принципиальная новизна моей идеи. :)
Мы можем считать это tar. Можем считать это сборником строк: key=value (base64)

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

Как их визуализировать и воспринимать - не дело стандарта. :) Дело клиента.

Я бы, конечно, предложил что то вроде key = value, но это вообще не важно.

# Re: idec
Peter(syscall,1) — Peter
2019-03-03 19:45:32


Короче, если инженерно, то это тег, ну пусть xdata/размер в байтах.
Этот блоб мы как нода фетчим за 1 доп запрос на сообщение.

А теперь клиенты(в том числе и веб).

Если это будет просто файл, то можно конечно, но как это определит софт? Что там, картинка или видосик? Поэтому я и думал, что в общем случае там мб какой то простой контейнер.

Ну смотрите, у нас же сообщение в определенном формате? Вот и тут, некий универсальный формат но допускающий бинарные данные.

Зачем? Не нарушена совместимость с ii. Старый софт пропустит текст, но не пропустит котика. И логическая сущность останется одна -- сообщение с msgid.

Так что для этих доп данных я придумал бы все таки что то простое, но все-таки допускающее задание ключ = блоб...

# Re: idec
vit01(mira, 1) — Andrew Lobanov
2019-03-03 21:09:12


AL> Ну вот. Можно что-то типа тега

AL> ====
AL> xdata/<filename>:<filesize>
AL> ====

Вот, это предложение уже конструктивно.

AL> заюзать и действительно ограничить на один файл на сообщение.

Да можно туда и несколько файлов засунуть.
xdata/filename1:filesize1:filename2:filesize2 и так далее

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

# Re: idec
vit01(mira, 1) — Andrew Lobanov
2019-03-03 21:22:04


AL> Надо уже выкидывать всё к чертям из стандарта. Реально полезным оказался только расширенный u/e. Остальное никому не впилось и все старательно не поддерживают эти фичи. Аттачи или изуродуем и раздуем, что сразу сделает их не лучше фэх, или не реализуем вовсе. Так что брошу я это дело. Файлы можно и в ТГ кинуть кому надо.

AL> Секта просрана. Люди боятся людей даже в таком маленьком обществе.

Зря ты так, зачем обижаться? Мы, с одной стороны, пытаемся делать софт чисто для себя (для чего сойдёт любая фигня, даже самое кривое API), но с другой стороны - на перспективу и за других всё равно думать надо бы.

Если кто-нибудь не хочет фэхи (или другой подобный протокол) на станции из-за опасений "нехорошего" контента, то он и так, и эдак их поддерживать не будет.

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

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

# Re: idec
Andrew Lobanov(tavern,1) — vit01
2019-03-04 04:36:46


AL>> Секта просрана. Люди боятся людей даже в таком маленьком обществе.
vit01> Зря ты так, зачем обижаться?

Это не обида. Просто вместо свободы общения подход сугубо инетовский. Хотя, ничего плохого в этом, пожалуй, и нет. Видимо, я иначе видел миссию секты =)

vit01> Мы, с одной стороны, пытаемся делать софт чисто для себя (для чего сойдёт любая фигня, даже самое кривое API), но с другой стороны - на перспективу и за других всё равно думать надо бы.

Можно и подумать.

vit01> Если кто-нибудь не хочет фэхи (или другой подобный протокол) на станции из-за опасений "нехорошего" контента, то он и так, и эдак их поддерживать не будет.

Конечно. Я ж не про то.

vit01> Правда, тот же Пётр мог бы просто не синхронизировать сам понимаешь какие фэхи и оставить ноду "чистой", но не хостить чужие файлы у себя он тоже полное право имеет.

Петру нужно место для общения про инстед. Он и сделал такое место. Бонных фэх у нас нет и это в текущих реалиях правильно.

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

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