Difrex> Как со стороны клиента должен выглядеть аплоад?

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

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

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

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

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

> Этот блоб мы как нода фетчим за 1 доп запрос на сообщение.

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

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

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

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

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

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

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

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

AL> ====
AL> xdata/:
AL> ====

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

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

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

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

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

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

xdata/:

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

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

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

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

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

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

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

> Реально полезным оказался только расширенный u/e.

vit01>> 1. Парсеры тегов в наших клиентах устроены так, что тег записывается в виде key/value, и нарушение такой симметрии испортит добавление новых тегов в будущем

AL> Нет.

Ага, то есть надо будет в парсере тегов городить отдельную проверку на xdata и возиться с говнокодом для каждого нового тега, чтобы не выйти за границы массива или ещё не совершить какую-нибудь глупость, которая всё порушит.

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

vit01>> Однозначно лишний запрос. Не хочу скачивать на свою мобилку кота в мешке на 100 мегабайт через платный лимитированный трафик.

AL> Если размер в тег кинуть, то и не скачаешь. И вообще сделать это для клиента делом добровольным.

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

А вот если перед нажатием кнопки "скачать" человек будет сразу видеть hot_naked_black_men.jpg (5 МБ), то тогда у него действительно появится выбор, качать или нет.

vit01>> На каждый тип файла делать свой костыль однозначно НЕ надо. Типа image, archive, music и.т.д. Расширения файла вполне достаточно, чтобы клиент распознал, что с файлом делать. Вдруг человеку захочется отправить какой-нибудь исполняемый или другой экзотический бинарник. Что, ради этого стандарт править?

AL> Зачем городить? file сделать и всё =)

Цитирую:

AL> Например:

> ====
> image::
> audio::
> ====

Не надо всяких image и audio, это избыточно и городит мусор с костылями в стандарте. Достаточно просто filename:base64

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

AL>> В теги просто проставляется метка. Типа так:

AL>> ====
AL>> ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata
AL>> ====

vit01> Надо в виде xdata/3 (3 файла в аттачах) или хотя бы xdata/4096 (общий размер вложений в байтах)
vit01> Потому что
vit01> 1. Парсеры тегов в наших клиентах устроены так, что тег записывается в виде key/value, и нарушение такой симметрии испортит добавление новых тегов в будущем

Нет.

vit01> 2. Знать размер файлов вложений полезно ещё до того как делать второй запрос.

Вот это полезно может быть.

Difrex>>> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.
AL>> Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.
vit01> Однозначно лишний запрос. Не хочу скачивать на свою мобилку кота в мешке на 100 мегабайт через платный лимитированный трафик.

Если размер в тег кинуть, то и не скачаешь. И вообще сделать это для клиента делом добровольным.

Peter>> Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.
vit01> На каждый тип файла делать свой костыль однозначно НЕ надо. Типа image, archive, music и.т.д. Расширения файла вполне достаточно, чтобы клиент распознал, что с файлом делать. Вдруг человеку захочется отправить какой-нибудь исполняемый или другой экзотический бинарник. Что, ради этого стандарт править?

Зачем городить? file сделать и всё =)

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

AL> В теги просто проставляется метка. Типа так:

AL> ====
AL> ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata
AL> ====

Надо в виде xdata/3 (3 файла в аттачах) или хотя бы xdata/4096 (общий размер вложений в байтах)

Потому что
1. Парсеры тегов в наших клиентах устроены так, что тег записывается в виде key/value, и нарушение такой симметрии испортит добавление новых тегов в будущем

2. Знать размер файлов вложений полезно ещё до того как делать второй запрос.

Difrex>> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.

AL> Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.

Однозначно лишний запрос. Не хочу скачивать на свою мобилку кота в мешке на 100 мегабайт через платный лимитированный трафик.

Peter> Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.

На каждый тип файла делать свой костыль однозначно НЕ надо. Типа image, archive, music и.т.д. Расширения файла вполне достаточно, чтобы клиент распознал, что с файлом делать. Вдруг человеку захочется отправить какой-нибудь исполняемый или другой экзотический бинарник. Что, ради этого стандарт править?

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

>> В теги просто проставляется метка
Difrex> Тогда, как заливать аттач вместе с постом?
Difrex> Расширять стандартное АПИ, чтобы принимало файлики или сразу постить
Difrex> в /x/d?
Difrex> * ii://RAvybDSreADX2RiJXr2c

>> Клиент видит тэг, запрашивает все аттачи по этому тегу
Difrex> Вот это не нравится. А если я не хочу все аттачи тянуть?

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

> В теги просто проставляется метка

> Зачем третий запрос?

> Клиент видит тэг, запрашивает все аттачи по этому тегу

>> Несколько файлов, например
Difrex> Вот этот момент не очень ясен. Т.е. в теги ты предлагаешь запихить что-то типа?
Difrex> ====
Difrex> ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata/BASE64(image)/xdata/BASE64(gpg signature)
Difrex> ====
Difrex> На сколько большими можно делать такие аттачи? Картинки довольно много весят, например.

ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata

>> Оно выглядит как гораздо более органичное развитие ii, нежели фэхи.
Difrex> Согласен, что это выглядит намного лучше, чем файловые эхи, которых у меня, кстати, нет :).

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

>Несколько файлов, например

ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata/BASE64(image)/xdata/BASE64(gpg signature)

>Оно выглядит как гораздо более органичное развитие ii, нежели фэхи.

AL>> Тут Пётр предложил идейку, которая позволит прилеплять дополнительные данные к сообщениям. Так станут ненужными ни фэхи ни фреки. Я пока в свободное время, коего очень немного, попиливаю концепт этого дела. Как будет что показать, выложу на поиграться в свободный доступ.
Difrex> Кстати, а может озвучишь идейку саму? :)

::

gkCo68TG1nrIXrgMklUN:filename:image.jpg
gkCo68TG1nrIXrgMklUN:image:

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

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

+++ At work. idec.el/0.1

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

Peter> Не выжил Рома. :(

+++ At work. idec.el/0.1