по поводу xml: http://bash.org.ru/quote/1989 :haha:

Значт так... Будем занимацо арифметикой;)

У нас есть JSON и XML&XSL. Рассмотрим ситуацию с моим сайтом. Контент и дополнительный функционал подгружается по запросу пользователя, а не всё в куче. Это логично, по-другому не придумаешь. Сюда значт входят:

XML
XSL
CSS (если надо, а надо практически всегда)
JS (если надо, а надо не всегда)

Дальше берём один раздел, к примеру "коды". Все страницы этого раздела используют 1 XSL, т.е. структура XML одинаковая, т.е. CSS нам нужен 1. Получается, что CSS и XSL мы в счёт брать не будем, т.к. они жестко закешируются при первом их запросе + для CSS запрос посылаться не будет. То же самое и с JS. При первом запросе закешируется, а потом даже запрашивать не будем. Идём дальше. При оптимизации структуры XML и XSL, получаемый XHTML будет на 10-30% тяжелее исходного XML. Выигрыш тут зависит от структуры XML и объёма создаваемой вёрстки (не считая обычной оптимизации в виде чистки мусора в коде). Считать мои килобайты пока рано, т.к. это не окончательный вариант, но уже что-то показывает... Погодите чуток). Получается, что при 2-3-4 и т.д. запросе контента этого раздела, мы устанавливает всего 1(!) соединение с сервером и экономим получаемый трафик на 10-30%. Для наглядности можно, конечно, это перевести в килобайты - кому надо - считайте. Если передавать это как JSON или обычный текст, мы наоборот будем терять эти проценты.

+ ко всему этому, сам XML тоже жёстко кешируется и при одинаковых запросах передаватся ничего не будет.

В случае же с JSON о преимуществах кэша можно забыть...

Вывод такой - использовать надо то, что актуально в каждом конкретном случае. JSON хорош там, где необходимо получить голые данные при одноразовых (индивидуальных) запросах. XML & XSL хороши там, где нужен именно контент (информация, а не данные). Такая связка даёт нам преимущества в виде кэша и уменьшение передаваемых байт. Это мой ответ на вопрос "одной личности" о том, почему же я это использую.

Хочу сделать последний акцент - именно XML & XSL, т.к. сам по себе XML только увеличивает объём из-за разметки и не подходит для "тупо данных".

ЗЫ: Если я что упустил/не учёл - пишите.

Нормально. Думаю стоит. Присмотритесь к фреймворку Ext JS

Спасибо, но этот сайт я делаю сам;)

что-то xsl у тебя постоянно запрашивается и не кэшируется

проценты это, конечно, круто, но пока что у тебя передается байт 200 в запросах (не нашел страницу с контентом). Пока что 30% это 200 -> 260. Офигительно сэкономили

теоретически да, на практике нужно считать. Например, при каком объеме с помощью xml можно будет устранить заметную задержку

а JSON типа нет

я ж ничего плохого в виду не имел

Еще стоит вспомнить, что не все сайты ведут программисты. И обычные пользователи наверняка не будут создавать xml-файлы, а тем более xsl, и еще и оптимизировать их под траффик

Вывод:
+ может быть получиться сэкономить на трафике, пока непонятно насколько
- нужно разобраться как его использовать (xml, xsl), хотя преимущества пока не очевидны

Пока не шлю заголовков принудительного кеширования.
Это всё понятно. Но в редких случаях такое возможно, если создавать только xml.
По логике вещей не должен, т.к.
эээ... Кому нужно разобратся?! не понял...

откуда такая информация? Откуда такая логика?

тем, кто его не знает

Можно написать интерфейс для таких...
Моя:thanks: А разве не так?

какое отношение имеет "где хорош JSON" к его кэшированию? Причем то, что JSON хорош только для голых данных, а тем более при одноразовых_запросах, это еще доказать нужно

Да никому это не нужно... Все будут делать так, как считают нужным. XML&XSL имеют право на использование в сети и с этим не поспоришь. Вот и пробуем использовать... Выходит не совсем всё так плохо, чтобы отказываться от этого...