>Несколько файлов, например
Вот этот момент не очень ясен. Т.е. в теги ты предлагаешь запихить что-то типа?

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

Её наличие даёт клиенту информацию, что для этого сообщения есть аттачи. То есть последовательность такая:

1. Качаем сообщения через u/e и u/m.
2. Тоссим их. В процессе запоминаем в каких сообщениях есть метка.
3. Запрашиваем аттачи.

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

Ну фэхи были сбоку по аналогии с фидонетом, где всё сбоку.

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

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

* ii://RAvybDSreADX2RiJXr2c
> Зачем третий запрос?
Да, получается, что два. Неправльно понял, как оно предпологается.
На схемке есть двойная стрелка, которая, символизирует два запроса :)

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

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

Пока в процессе это всё. Хочу и так и этак попробовать, а там уже смотреть.

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

Тогда просто игнорируешь тег и всё.

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

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

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:<filename>:<base64>
> audio:<filename>:<base64>
> ====

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

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