[#]
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/<filename>:<filesize>
заюзать и действительно ограничить на один файл на сообщение.
На тему того, что не обязательно это должен быть файл, я хочу заметить, что пользователям не нужны абстрактные сферические данные. Им нужны файлы =)
[#]
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 и так далее
[#]
Re: idec
vit01(mira, 1) — Andrew Lobanov
2019-03-03 21:22:04
AL> Надо уже выкидывать всё к чертям из стандарта. Реально полезным оказался только расширенный u/e. Остальное никому не впилось и все старательно не поддерживают эти фичи. Аттачи или изуродуем и раздуем, что сразу сделает их не лучше фэх, или не реализуем вовсе. Так что брошу я это дело. Файлы можно и в ТГ кинуть кому надо.
AL> Секта просрана. Люди боятся людей даже в таком маленьком обществе.
Зря ты так, зачем обижаться? Мы, с одной стороны, пытаемся делать софт чисто для себя (для чего сойдёт любая фигня, даже самое кривое API), но с другой стороны - на перспективу и за других всё равно думать надо бы.
Если кто-нибудь не хочет фэхи (или другой подобный протокол) на станции из-за опасений "нехорошего" контента, то он и так, и эдак их поддерживать не будет.
Правда, тот же Пётр мог бы просто не синхронизировать сам понимаешь какие фэхи и оставить ноду "чистой", но не хостить чужие файлы у себя он тоже полное право имеет.
Нетмейл нам нужен в каком-то смысле, но вряд ли у меня будет хватать смекалки и времени самому продумать, как это дело может работать. Но, тем не менее, его надо бы реализовать.
[#]
Re: idec
Andrew Lobanov(tavern,1) — vit01
2019-03-04 04:36:46
AL>> Секта просрана. Люди боятся людей даже в таком маленьком обществе.
vit01> Зря ты так, зачем обижаться?
Это не обида. Просто вместо свободы общения подход сугубо инетовский. Хотя, ничего плохого в этом, пожалуй, и нет. Видимо, я иначе видел миссию секты =)
vit01> Мы, с одной стороны, пытаемся делать софт чисто для себя (для чего сойдёт любая фигня, даже самое кривое API), но с другой стороны - на перспективу и за других всё равно думать надо бы.
Можно и подумать.
vit01> Если кто-нибудь не хочет фэхи (или другой подобный протокол) на станции из-за опасений "нехорошего" контента, то он и так, и эдак их поддерживать не будет.
Конечно. Я ж не про то.
vit01> Правда, тот же Пётр мог бы просто не синхронизировать сам понимаешь какие фэхи и оставить ноду "чистой", но не хостить чужие файлы у себя он тоже полное право имеет.
Петру нужно место для общения про инстед. Он и сделал такое место. Бонных фэх у нас нет и это в текущих реалиях правильно.
vit01> Нетмейл нам нужен в каком-то смысле, но вряд ли у меня будет хватать смекалки и времени самому продумать, как это дело может работать. Но, тем не менее, его надо бы реализовать.
Нетмейл очень нужен. Я даже иногда думаю как бы его половчее сделать, но пока взялся писать кандидата в эталонные реализации idec.