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