Соответственно встал вопрос о переносе контактов на новый сервер. Чем это можно сделать? Конечно же Jabber Roster Utility, чем же еще? Но! JRE сначала должен получить контакты со старого, а сервер-то лежит. Ростер, конечно же, скеширован клиентом, коим у меня является Psi. Но формат-то там неподходящий! Если перебивать ручками, то проще покажется добавить ручками же контакты прямо в клиенте. Не вариант.

Сначала в голову полезла шальная мысль написать парсер, но она была сразу отброшена. Psi хранит настройки в XML, a значит можно поступить проще.

Возьмем нужный нам файл настроек: %psidatadir%/profiles/%profilename%/accounts.xml и применим к нему xslt-стиль. Стиль этот очень прост:

<?xml version=”1.0″ encoding=”UTF-8″?>

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns=”http://psi-im.org/options”>
<xsl:output method=”text”/>

<xsl:template match=”/accounts/accounts/*”>
Account <xsl:value-of select=”jid”/><xsl:apply-templates select=”roster-cache”/>
</xsl:template>

<xsl:template match=”roster-cache/*”>+,<xsl:value-of select=”jid”/>,<xsl:value-of select=”name”/>,none,<xsl:value-of select=”groups/item”/></xsl:template>

</xsl:stylesheet>

В результате мы получим ростеры всех прописанных туда аккаунтов в формате, который хавает JRE

Account jid@domain.tld
+,elem1@dom1.tld,Element 1,none,Group
+,elem2@dom2.tld,Element 2,none,Group
+,elem3@dom3.tld,Element 3,none,Group 2

Account jid2@domain2.tld
+,elem1@dom1.tld,Element 1,none,
+,elem4@dom4.tld,Element 2,none,

Вуаля, кормим JRE.

Как применить стиль?

Самый простой способ — браузер. Открываем accounts.xml (рекомендую сделать копию и издеваться над ней, а не резать по живому), вписываем первой строкой

<?xml-stylesheet type=”text/xsl” href=”accounts-xslt.xml”?>

копируем стиль в папку с этим accounts.xml и открываем accounts.xml в браузере.

Если не сработает, удаляем из accounts.xml строку <!DOCTYPE accounts> и элемент xmlns=”http://psi-im.org/options”

Знаю, что не по фэн-шую, но мне почему-то помогло.

Скачать стиль: http://misc.sunchaser.info/software/psi2jre.zip

Ахда, в любых XML документах нельзя указывать DTD, иначе Internet Explorer пойдет по указанному адресу его скачать. Всё бы ничего, но он этим ddos-ит www.w3.org, поэтому там забанен. А значит, он просто вместо документа покажет ошибку

Проверялось на примере avalon.com.ru

1) Google

Индексирует, игнорируя стили. Отчасти даже лучше — оформление не попадает в индекс и не мешается при поиске, но для полноты индексации надо делать sitemap.

2) Yahoo!

Применяет стиль и индексирует результат. Вах! То, что надо.

3) Yandex, Rambler, Aport, Microsoft Bing, Baidu

Никак. Стыд и позор!

Что ж… к сожалению, такой технически удачный подход к созданию сайтов слегка нежизнеспособен.

Правда, выход есть — прогонять XML через серверный скрипт, который при необходимости (для поисковиков или неподдерживаемых браузеров) будет применять стиль прямо на сервере, а иначе просто отдавать чистый XML.

Обычно XSLT в вебе используется для преобразования XML-документов в XHTML на стороне сервера. В результате получается обычная HTML-ка, которая передается в браузер. Это не интересно и никак не отражает некоторых прелестей XSLT-преобразования.

Работа с XML и, в частности, XSLT-преобразование является стандартной функцией современных браузеров. Почему бы не заюзать преобразования на стороне клиента?

Выглядит, скажем, наша главная страница как

И уже в браузере формируется в приветствие, блок поиска и блок новостей и оборачивается в оформление сайта.

Такой подход используется, например на сайте starcraft2.com и сайте avalon.com.ru, над которым я время от времени и колдую.

Посмотрим на достоинства и недостатки:

Достоинтсва:

1. Разделение данных и представления. Это типа хорошо и этого всегда добиваются
2. Снижение нагрузки на сервер. Точнее, на вебовский фронт-энд, так как ему уже не надо по куче шаблонов формировать удобочитаемое представление
3. Снижение трафика. Шаблоны достаточно скачать один раз и закешировать. Собственно, тот же эффект, что и от CSS

Недостатки:

1. Требуется более высокое качество кода. Корявый HTML коряво отображается. Корявый XML не отображается вообще (на самом деле это достоинство, но моду диктуют “индусы” и другие быдлокодеры)
2. Нагрузка на клиента. Современные браузеры на XSLT-страничках заметно подтормаживают, особенно, разумеется, Internet Explorer. Тонкий клиент как бы “толстеет”
3. Browser Wars. Стоит просто у валидной XHTML-странички сменить тип с text/html на text/xml, сразу же всплывают какие-то странные несовместимости у браузеров. А, например, открытые реализации KHTML/WebKit (напр, Konqueror и Arora) вообще XSLT не понимают

Непонятки:

1. Поисковики. Как поисковики относятся к XSLT? А хз. Требует дополнительного исследования

В целом, снятие нагрузки с интерпретатора на сервере и с моих мозгов перевешивает для меня минусы подхода. В скором будущем напишу подробнее о поддержке браузерами и, если что узнаю, поисковиками