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

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

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

>> Несколько файлов, например
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
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

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

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

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

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

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

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

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

>>>> Клиент видит тэг, запрашивает все аттачи по этому тегу
>>> Вот это не нравится. А если я не хочу все аттачи тянуть?
>> Тогда просто игнорируешь тег и всё.
Difrex> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.

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

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

Peter> Идея была все-таки вот в чем.
Peter> С сообщением могут идти данные. Формат данных и что в них, мы не стандартизируем. Это просто данные, связанные с сообщением.
Peter> Поэтому детализация на таком уровне, по моему, принесет только вред. Тогда лучше остаться на том, что есть.
Peter> Просто есть дополнительная инфа. Что именно в этой информации определяет клиентское ПО. Там могут быть картинки, звук.
Peter> Ну как в современных мессенжерах. :)

Peter> А выбирать пропускать данные или нет нода может только руководствуясь лимитами на размер. Скажем, размер данных не больше 1Мб.

> Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов.

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

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

image::
audio::

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

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