Вышла версия 17 почтового клиента Thunderbird

Я тёмный, малограмотный человек. Всю жизнь думал, что im-клиент должен коннектиться к im-серверу, а не к сайту.

Как-то я запустил его через sudo (надо было посмотреть message.eml)

Здесь разжуйте для дурака.

Хм, кто еще пользуется почтовыми клиентами, тем более комбайнами? Удобнее гугловского веб-интерфейса ИМХО еще ничего не придумали.

По мотивам старой копипасты: почтовый клиент удобнее и безопаснее. Например:

1. Веб-почту могут угнать через XSS/javascript. Отключить скрипты нельзя — веб-морда работать перестанет. Такие баги вылазят регулярно, их периодически фиксят. Через почтовый клиент невозможно незаметно угнать почту, скрипты отключаются полностью, баги взять негде.

2. В почтовом клиенте, если выставить SSL, то все данные передаются шифрованными, и их никто не перехватит. В веб-интерфейсах часто открытым текстом передаются письма, а иногда — даже пароли.

3. В почтовом клиенте можно управлять цепочками так, как это нужно. Хочешь — все письма раздельно, хочешь — будут группироваться в цепочки или дерево. Можно переместить отдельное письмо в другой каталог, или отметить одно единственное письмо как непрочитанное, чтобы потом перечитать его (невозможно в gmail).

4. При изменении заголовка письма в почтовом клиенте оно не идет в отдельную цепочку (снова камень в огород gmail-а).

5. Не бывает проблем с кодировкой писем. Можно всегда переключить кодировку на нужную.

6. В почтовом клиенте можно легко изменить поле From у отправляемого письма (когда общаешься на разных языках не приходится держать From английским). В веб-интерфейсах это либо невозможно, либо делается через одно место.

7. Если сочетания клавиш не нравятся — их можно изменить.

8. В почтовом клиенте можно настроить автоперенос длинных строк (или, еще лучше, мягкий перенос, как в sylpheed claws).

9. Можно настроить сортировку писем в подкаталоги по любому заголовку, а не только по From/To/Subject, это позволяет фильтровать по разным каталогам любые рассылки и письма от багзилл, а не копаться в общей куче в INBOX.

10. В почтовом клиенте можно настроить индивидуальные шаблоны для подкаталогов. Если я нажму «Написать письмо» в каталоге рассылки, то в открывшемся окне будет заполнен адрес рассылки в поле From, а в тексте заранее стоять заголовок и хвост письма (например, «Привет, ЛОР» и «С уважением, анонимус»). Мне ещё не попадались веб-интерфейсы, где это можно было бы сделать.

А еще в почтовом клиенте нужное письмо можно найти даже когда нет интернета, или когда лежит почтовый сервер. И не приходится опасаться, что всякие gmail/mailru привяжут к почтовому ящику историю посещенных сайтов.

Зачем нужны веб-интерфейсы, когда есть удобные и безопасные почтовые клиенты?

Под виндой Thunderbird любят за возможность шифровать почту.

Скайпик таки оказываются надёжнее в этом случае [...] отсылает данные от пользователя к пользователю «напрямую».

Уже давно не напрямую, а через ноды макрософта.

У меня нет протоколов, кроме XMPP, а жить даже без Service Discovery как-то не очень.

Почему «без Service Discovery»? Он же там есть...

К тому же, XHTML-IM там ну просто наркоманский.

Наоборот. Помнится, в «продвинутых» клиентах, вроде psi+, только-только собирались допиливать его поддержку в то время, как в pidgin-е оно уже давно было. И с поддержкой голоса/видео в жаббере было так же — pidgin был одним из первых, если не первым, кто её добавил.

ну тут в ветке ниже уже подсказали:
* упорное нежелание разрабов добавить опцию отсылки сообщений по Ctrl+Enter

Какое же нежелание, это ещё в gaim-е можно было сделать...

* удаление графической диференциации протоколов

которое не состоялось

* Невменяемый формат хранения логов

Plain text — самый вменяемый из всех. Доступен из под любой операционки, удобно разложен по каталогам. Можно хоть grep-ом по нему искать, хоть KDE-шным поиском индексировать, если руки чешутся.

поле отсылки с авторесайзом.

Кстати, очень удобная фича. Раньше приходилось руками ресайзить, а теперь автоматически. К тому же размер поля всё равно настраивается.

Итого, все претензии к pidgin-у какие-то несуществующие. А учитывая море готовых плагинов для него и возможность писать их даже на перле, я не представляю, какой клиент может быть лучше pidgin-а.

В целом, это не важно. Важно, что если у пользователя есть подключение к скайпу, то файлег он получит «сейчас», а не через трое суток, после того, как промежуточный SMTP сервер где-нибудь в Тринидаде разгребёт свою засранную очередь. Не, я понимаю, к выбору провайдера, равно как и к выбору вторичных MX'ов надо относится тщательнее, но, в целом, это может оказаться вне контроля конечного ендлузера.

Почему «без Service Discovery»? Он же там есть...

Возможно, мои данные устарели. А adhoc commands? :)

Наоборот. Помнится, в «продвинутых» клиентах, вроде psi+, только-только собирались допиливать его поддержку в то время, как в pidgin-е оно уже давно было. И с поддержкой голоса/видео в жаббере было так же — pidgin был одним из первых, если не первым, кто её добавил.

Может так оно и было, но на данный момент пиджин все параграфы месит в одно строку, делая всё нечитаемым, напоролся, когда отлаживал LiJ. Опять же, может за это время что-то изменилось.

пиджин все параграфы месит в одно строку, делая всё нечитаемым

«вставить как простой текст»

А других кодировок там нет? Только письма с кои-8?

Ну, recode, например, не будет превращать UTF-8 в UTF-8 %) Не знаю, правда, как с одноклеточными кодировками, но в любом случае можно определять их автоматически (enca или ещё чем-нибудь).

Причем тут вставить, мой сервис присылает XHTML, который выглядеть начинает как мешанина.

С юникодом всё понятно, а вот с остальными... Задача не столь проста, ка кажется. Если бы хоть раз попробовал нечто подобное сделать с рабочим ящиком, едва ли стал бы такие советы давать )

а, то есть, это входящие... ну, не знаю, не сталкивался с таким. Хотя, на пиджине я давно.

Увы, не полноценная. Или я отстал от жизни, и Thunderbird может работать как клиент M$ Exchange?

Если админы нормальные и дают imap/smtp/чтотамеще, то может :) Если не дают.. тоже может, через davmail :) Письма, календарь, адресная книга есть. Может еще что-то бывает, но лично мне и того с головой.

ExQuilla

У меня с ней акк не создавался. На вопрос на форуме не ответили. Со свободностью там вроде плохо. // предыдущий анонимус

Скайпик и гугледрайвик таки оказываются надёжнее в этом случае. Первый - потому что отсылает данные от пользователя к пользователю «напрямую».

А сам скайп согласен?

http://flylib.com/books/3/92/1/html/2/images/skypehks_0522.jpg

эта зараза сама скачивает обновление и устанавливает его при перезапуске

man app.update.channel

Может так оно и было, но на данный момент пиджин все параграфы месит в одно строку, делая всё нечитаемым, напоролся, когда отлаживал LiJ.

Хм. У меня наоборот из всех тестировавшихся когда-то клиентов отображение сообщений в pidgin-е было одним из самых корректных. А баг воспроизводим? А то если это единственная проблема, то можно ж и багрепорт написать, и патч отправить... :)

Возможно, мои данные устарели. А adhoc commands? :)

Судя по исходникам, уже лет 5. Но я не очень представляю, как проверить, работает ли оно. Предлагаю быстренько поставить и убедиться самому. В конце концов, это ж не винда, поставить прогу, потестить, и удалить — легко и быстро.

You just don't understand! Only Web! Only Google! No thinking required!11

А баг воспроизводим?

Завтра буду на работе, перепроверю, выложу скриншот, если повторится. Давно не занимаюсь этим проектом, потому что XSF сильно пробуксовывает в принятии нужных стандартов.

Предлагаю быстренько поставить и убедиться самому

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

davmail

Это http://davmail.sourceforge.net/ Благодарю, гляну

Письма, календарь, адресная книга есть

Через imap/smtp/чтотамеще, или через davmail?

Не, с XHTML-IM всё по старому:

http://jrudevels.org/Trash/pidgin-lijuick-xhtml-fail.png

Вот как он рендерит, и вот, что есть в HTML:

<html xmlns='http://jabber.org/protocol/xhtml-im'>
  <body xmlns='http://www.w3.org/1999/xhtml'>
    <p>Publisher is 	<a href='xmpp:news.opensource@lor.jrudevels.org'>xmpp:news.opensource@lor.jrudevels.org</a>
    </p>
    <p>
      <strong>
        <a href='xmpp:linuxmaster@users.lor.jrudevels.org'>linuxmaster@users.lor.jrudevels.org</a>
      </strong>:
    </p>
    <div>
	<h3>Внедрение Linux в госучреждениях Мюнхена позволило сэкономить 10 млн евро</h3>
	<p>Немцы наскоком ничего не делают. Всё было продумано и просчитано. Я гарантирую это.</p>
    </div>
    <ul>
	<li>Alternative: 	<a href='http://www.linux.org.ru/jump-message.jsp?msgid=8510785&cid=8517099'>http://www.linux.org.ru/jump-message.jsp?msgid=8510785&cid=8517099</a>
        </li>
        <li>Root post:	<a href='xmpp:news.opensource@lor.jrudevels.org?;node=urn%3Axmpp%3Amicroblog%3A0;item=8510785'>[Link]</a>
        </li>
    </ul>
    <p/>
    <p>
	<a href='xmpp:news.opensource@lor.jrudevels.org?;node=8510785;item=8517099'>#2979</a>
    </p>
  </body>
</html>

Т.е. на параграфы оно просто кладёт прибор. Вот как примерно то же самое выглядит в Psi: http://jrudevels.org/Trash/psi-lijuick-lor-threads.png Галерея в гаджиме: http://jrudevels.org/Trash/gajim-lijuick-lor-gallery.png

Т.е. везде всё хорошо, кроме пиджина. Ad-hoc комманд в интерфейсе тоже нет, чего бы там ни было в сорцах.

Так что ничего не поменялось.

Pidgin 2.10.6 (libpurple 2.10.6), gentoo.

локальный почтовик давно не нужон! :)

кому как

Не, с XHTML-IM всё по старому:
http://jrudevels.org/Trash/pidgin-lijuick-xhtml-fail.png

Тю, это какая-то самописная утилита, что-ли?

Вот как он рендерит, и вот, что есть в HTML:

Итак, навскидку, я вижу 3 бага:
1. Не поддерживаются теги H3 и DIV, причём на их поддержку расчитывать не очень стоит, они даже не относятся к рекомендуемым в XEP-0071.
2. Не поддерживаются списки UL/LI, багрепорт: https://developer.pidgin.im/ticket/9804 но похоже, никому это особо не надо, поскольку кроме чьих-то самописных утилит их больше никто не использует.
3. Разрыв строки делается только по BR, а теги P игнорируются. Исправить несложно, но видимо это настолько никому не нужно, что я даже багрепорта на эту тему не вижу.

Проблемы #2 и #3 вполне можно починить, но для этого неплохо бы иметь причину. На фразу «моя программа не работает с вашим клиентом» девелоперы могут ответить «почини свою программу» и будут в чём-то правы, ведь они даже не могут воспроизвести проблему. Вот если бы найти какие-нибудь общеизвестные сервисы, где вылазит такой же баг, чтобы не идти в багтрекер с пустыми руками...

Т.е. на параграфы оно просто кладёт прибор.

Судя по всему, их никто не использует. Все клиенты, которые мне попадались, делают разрыв строки тегом BR, и pidgin его обрабатывает.

Т.е. везде всё хорошо, кроме пиджина.

В psi в любом случае будет «всё хорошо». Емнип, он банальный веб-браузер использует, ему можно по жабберу и HTML-ку с яваскриптами отправить, он её тоже отрендерит.

На тему «всё хорошо», это для данного бота у них всё хорошо, а с обычными клиентами там косяки вылазят. Я уже сейчас не помню, у кого из них какие, помню, что некоторые клиенты глотали разрывы строк и пробелы — в отформатированном пробелами куске кода клиент терял все пробелы, кроме одного. Кстати, это не у gajim-а ли был баг, что он не мог получить список комнат с conference.jabber.org и зайти в комнаты со знаками подчёркивания в имени? Да и комментарии «GdkPixbuf is not safe... this program is now potentially hackable ;)» в исходниках gajim-а как-то не внушают к нему доверия...

Ad-hoc комманд в интерфейсе тоже нет, чего бы там ни было в сорцах.

Есть ли какой-то общедоступный способ это проверить? Кроме самописных утилит?

Итого, главный вопрос: где обычные пользователи jabber-а могут столкнуться с этими проблемами, и где девелоперы могут их воспроизвести?

Те, кому нужно получать письма сразу с десятка аккаунтов. К сожалению, интерфейс Gmail на такое явно не рассчитан. Мало того, даже объединить все свои аккаунты Google под одним профилем не получается. Парни из Google наверно думают, что у каждого человека должен быть один аккаунт.

да ладно, сто лет сижу на gmail с десятком почтовых учеток, все там с этим впорядке

Тю, это какая-то самописная утилита, что-ли?

Я тебе открою секрет: ВСЕ утилиты кто-то написал, так что я не понимаю, какое это имеет значение.

Итак, навскидку, я вижу 3 бага:

Параграфы то рекоммендуются, без h3 пережить можно, а вот без параграфов — нет.

Проблемы #2 и #3 вполне можно починить, но для этого неплохо бы иметь причину. На фразу «моя программа не работает с вашим клиентом» девелоперы могут ответить «почини свою программу»

Нет, не могут, если моя программа соответствует XEP.

Судя по всему, их никто не использует. Все клиенты, которые мне попадались, делают разрыв строки тегом BR, и pidgin его обрабатывает.

Писать клиенты, изучая протокол по XML-консоли очень удобно, да, я сам так делал, будучи школьником. :)

В psi в любом случае будет «всё хорошо». Емнип, он банальный веб-браузер использует, ему можно по жабберу и HTML-ку с яваскриптами отправить, он её тоже отрендерит.

Да не дай Б-г!

Я уже сейчас не помню, у кого из них какие, помню, что некоторые клиенты глотали разрывы строк и пробелы — в отформатированном пробелами куске кода клиент терял все пробелы, кроме одного.

Так может и нет уже таких проблем? Напомню, я специально перепроверил всё на свежем пиджине, чтобы не соврать.

Кстати, это не у gajim-а ли был баг, что он не мог получить список комнат с conference.jabber.org и зайти в комнаты со знаками подчёркивания в имени?

Понятия не имею, причём тут XHTML? Опять же, говорим об актуальных проблемах, ладно?

Есть ли какой-то общедоступный способ это проверить? Кроме самописных утилит?

http://jawiki.ru/Translate-service

Я негодую, почему самописный pidgin не работает с моим сервисом! %) Есть ещё j2j и даже ejabberd'овская админка на adhoc. Также очень многие клиенты умеют remote control, который тоже adhoc. Даже андроидовский jtalk умеет adhoc.

обычные пользователи jabber-а

Это какие? Пользователи чатика вконтакте? Наверно, нигде. Но они и про пиджин ничего не знают, увы.

P.S. А вообще, мне очень странен ваш тон.

Как вы держите все аккаунты открытыми одновременно? Что-бы при получении письма сразу его прочесть? Просто интересно, у меня одновременно в одной вкладке умещается только один почтовый аккаунт. Или вы открываете десять вкладок для десяти аккаунтов? Неудобно как-то получается.

Как вы держите все аккаунты открытыми одновременно? Что-бы при получении письма сразу его прочесть? Просто интересно, у меня одновременно в одной вкладке умещается только один почтовый аккаунт. Или вы открываете десять вкладок для десяти аккаунтов? Неудобно как-то получается.

забираю через pop/imap в один ящик

Я тебе открою секрет: ВСЕ утилиты кто-то написал, так что я не понимаю, какое это имеет значение.

Имелась ввиду утилита внутреннего пользования, недоступная большинству, и в частности разработчикам pidgin-а.

Да не дай Б-г!

А что, это фича же! Можно лазить по сети прямо в окне жаббера, заодно переписываясь с друзьями. :)

Так может и нет уже таких проблем? Напомню, я специально перепроверил всё на свежем пиджине, чтобы не соврать.

Gajim 0.15.2. Не может забрать список конференций с jabber.org. Проглатывает пробелы в форматировании. И это то, что видят все пользователи, без всяких хитрых ботов и сервисов. :) Баг с подчёркиваниями воспроизвести не удалось, но это было несколько лет назад, я уже и не помню, в каких условиях он вылазил.

Есть ли какой-то общедоступный способ это проверить? Кроме самописных утилит?

http://jawiki.ru/Translate-service

О, это уже что-то. Есть аналогичная статья для англоязычных пользователей? Или аналогичный сервис, желательно более-менее известный среди англоговорящей аудитории? Это касается и поддержки параграфов и AdHoc-команд. Скидывать в английский багтрекер ссылку на русскую вики как-то неправильно...

Есть ещё j2j и даже ejabberd'овская админка на adhoc. Даже андроидовский jtalk умеет adhoc.

То есть, чтобы проверить adhoc надо поставить ejabberd или купить андроид и установить jtalk? А попроще нельзя? ;) Обычный service discovery в pidgin-е же работает...

P.S. А вообще, мне очень странен ваш тон.

Прошу прощения. Я перефразирую.

По поводу pidgin-а речь шла о том, что я не отрицаю баг, но ищу что-нибудь, с чем можно было бы пойти в багтрекер, чтобы указать на «важность» этой проблемы.

По поводу форматирования и «у всех всё хорошо» речь шла о том, что у pidgin-а одна из самых адекватных реализаций оформления. Да, он лажает в таких редких уникальных случаях. Но остальные лажают даже при обычном обмене обычными сообщениями.

А по поводу gajim-а речь шла о том, что помимо прочих багов мне и сам клиент местами не внушает доверия. :)

Имелась ввиду утилита внутреннего пользования, недоступная большинству, и в частности разработчикам pidgin-а.

Если разработчики pidginа не могут сваять себе пример с параграфами, то я прямо не знаю. А если они таки ваяют xmpp-клиент по XML-консоли, то пиджин таки и не заслуживает внимания как полноценный XMPP-клиент, о чём и была речь.

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

Если ты дашь им ссылку на xmpp:translate.jrudevels.org, я думаю, они разберутся, не выдумывай себе и мне трудностей на пустом месте. btw, сей сервис написан мной, так что для тебя он, наверно, тоже «самописный». Вообще, я как-то представлял себе, что могу пойти в багтрекер вообще без какого-либо сервиса, просто описав ситуацию, и указав, почему я прав. Собственно, с багтрекером гаджима я так и поступаю, и проблемы решаются весьма оперативно. Так же не делаю с пиджином потому, что не воспринимаю его как нормальный xmpp-клиент, а как комбайн, которому такие мелочи ни к чему. Может я и не прав.

То есть, чтобы проверить adhoc надо поставить ejabberd или купить андроид и установить jtalk? А попроще нельзя? ;) Обычный service discovery в pidgin-е же работает...

Причём тут это? Достаточно указать на XEPы: http://xmpp.org/extensions/xep-0146.html и http://xmpp.org/extensions/xep-0133.html

А дальше уже не ваши заботы. А если ты ещё и укажешь, что поставить, чтобы протестить, цены тебе не будет, я считаю.

По поводу форматирования и «у всех всё хорошо» речь шла о том, что у pidgin-а одна из самых адекватных реализаций оформления

Нет, это не так.

Да, он лажает в таких редких уникальных случаях

Уникальные параграфы, ну-ну.

А по поводу gajim-а речь шла о том, что помимо прочих багов мне и сам клиент местами не внушает доверия

Субъективизм меня не очень волнует. Объективно, по части xmpp лучшего практически и нет сейчас.

Если разработчики pidginа не могут сваять себе пример с параграфами, то я прямо не знаю.

Вопрос не в том, чтобы сваять, а в целесообразности заниматься этой конкретной проблемой. Почему они должны реализовывать именно этот draft, а не любой другой из сотни XEP-ов или других проблем/задач? Эта проблема актуальнее других? Тогда именно это и надо продемонстрировать.

Если ты дашь им ссылку на xmpp:translate.jrudevels.org, я думаю, они разберутся,

Ну и где тут видно проблему?

не выдумывай себе и мне трудностей на пустом месте.

Я не трудности выдумываю, я пытаюсь понять, действительно ли это проблема клиента, или это проблема одного конкретного сервиса, которая кроме как в нём больше нигде не проявляется.

btw, сей сервис написан мной, так что для тебя он, наверно, тоже «самописный».

Вопрос не в авторе. Вопрос в актуальности проблемы. Она вылазит только для десятка русскоязычных юзеров одного сервиса в мире? А может этот сервис используется и англоязычными юзерами тоже (есть статьи)? Или она встречается где-то ещё?

Вообще, я как-то представлял себе, что могу пойти в багтрекер вообще без какого-либо сервиса, просто описав ситуацию, и указав, почему я прав.

Если не важен результат, то можно так и сделать. Только есть риск, что баг посчитают никому не нужной хотелкой одного юзера, и он будет висеть годами.

Причём тут это? Достаточно указать на XEPы

И получить ответ «WORKSFORME». Проблема ведь названа не была.

А если ты ещё и укажешь, что поставить, чтобы протестить, цены тебе не будет, я считаю.

Так именно это я ж и пытаюсь выяснить. Мне пока что тоже не очень понятно, как воспроизвести проблему. Steps to reproduce — основа любого багрепорта. Чем больше юзеров затрагивает эта проблема , тем выше шанс её быстрого исправления. Поэтому я и спрашиваю — есть ли какие-либо примеры, англоязычные статьи или общедоступные англоязычные сервисы, на которые можно было бы сослаться, указав на наличие проблемы?

Уникальные параграфы, ну-ну.

Если кроме этого единственного на весь рунет сервиса их никто не использует, то да, получается, что уникальные. :)

Объективно, по части xmpp лучшего практически и нет сейчас.

Объективно? Объективно у него есть баги, которые вылазят для обычных юзеров при повседневном общении, и которых в других клиентах нет. Особой функциональностью или плагинами он тоже не блещет. Где же лучшесть?

забираю через pop/imap в один ящик

А отправка с определенного ящика? Поиск, просмотр сообщений отправленных/удаленных/и_тд по всем ящикам? Таки требует наличия «десяти вкладок».

И если при отправке достаточно перейти на нужную, то для поиска потребуется перебрать все 10. Вот это я понимаю «удобно».

А отправка с определенного ящика?

В гмейле это можно настроить. Можно даже чтобы автоматически подставлялся в качестве отправителя адресс, на который пришло письмо.

Поиск, просмотр сообщений отправленных/удаленных/и_тд по всем ящикам?

Ну если ты собираешь их всех в один ящик, в чем тут проблема?

да, согласен, я немного брутально сказал... единственное требование (имхо) это работа с почтой в офлайне

Вот это я понимаю «удобно».

люблю, когда люди с умным видом начинают рассказывать про то, чем никогда не пользовались))

А отправка с определенного ящика?

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

Поиск, просмотр сообщений отправленных/удаленных/и_тд по всем ящикам?

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

Таки требует наличия «десяти вкладок».

итого, нет, не требуется, достаточно одной

И если при отправке достаточно перейти на нужную, то для поиска потребуется перебрать все 10.

можно делать и так, если хочется иметь 10 разных интерфейсов и геморрой с поиском :)

Вопрос не в том, чтобы сваять, а в целесообразности заниматься этой конкретной проблемой. Почему они должны реализовывать именно этот draft, а не любой другой из сотни XEP-ов или других проблем/задач? Эта проблема актуальнее других? Тогда именно это и надо продемонстрировать.

Целесообразность простая: не завязываться на частный случай, а то у нас и так проблема перманентная курицы и яйца: клиенты не реализовывают, потому что никакие сервисы это не используют, а сервисы не используют, потому что с половиной клиентов это не будет работать. А в случае с pidgin'ом без костылей ещё и не определишь, что XHTML пользовать не стоит, ибо он то считает, что XHTML поддерживается и отсылает это в своих features. Так что лучше вообще не поддерживать XHTML, чем поддерживать так, как это делает пиджин, или даже ткаббер.

И получить ответ «WORKSFORME». Проблема ведь названа не была.

Если они умеют читать, то сами поймут, в чём проблема: нельзя удалённо управлять своими клиентами и своими серверами. Если это посчитают ненужным обычным ™ пользователям, так тому и быть, но тогда чего обижаться, когда говорят, что лучше конкретно для xmpp использовать что-то другое?

Ну и где тут видно проблему?

Ну если для тебя не очевидно, что не получается выполнить команды, которые «Commands», то я прямо даже не знаю...

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

XEPы. Названия клиентов и серверов с remote control.

Если кроме этого единственного на весь рунет сервиса их никто не использует, то да, получается, что уникальные

Такими темпами, никто и не будет использовать. Почему: я объяснил выше. Поэтому я положил болт на поддержку пиджина с чистой совестью, ибо всем не угодишь, пусть сами свои баги правят.

Объективно? Объективно у него есть баги, которые вылазят для обычных юзеров при повседневном общении, и которых в других клиентах нет. Особой функциональностью или плагинами он тоже не блещет. Где же лучшесть?

У всех есть баги. Я использую гаджим очень плотно каждый день, в том числе, и в разработке. И, в отличие от пиджина, проблем не вижу, а которые вижу, репорчу и быстро получаю фикс. Вот и лучшесть. Ничего не имею против пиджина как комбайна, но говорить, что он хорош для xmpp пока рано. Да блин, какой хороший клиент не показывает статусы пользователей в MUC?

Целесообразность простая: не завязываться на частный случай, а то у нас и так проблема перманентная курицы и яйца: клиенты не реализовывают, потому что никакие сервисы это не используют, а сервисы не используют, потому что с половиной клиентов это не будет работать.

Так может наоборот, стоит убрать <P> из стандарта, как никому не нужный? Всё равно стандарт — draft, и есть BR.

Так что лучше вообще не поддерживать XHTML, чем поддерживать так, как это делает пиджин, или даже ткаббер.

Его почти никто не поддерживает. Думаю, параграфы не используют потому, что легко нарваться на баг вроде <p>text<b>is</p><p>bold</b></p>, которое можно встретить в HTML, но нельзя использовать в jabber-е. И даже если учесть такие случаи, параграфы всё равно трудно поддерживать.

Тот же gajim делает это криво даже в обычных сообщениях. Например:
* <html ...><body ...><p>text</p></body></html> gajim показывает две строки вместо одной
* <html ...><body ...><p>line1<br/>line2</p></body></html> gajim показывает три строки вместо двух
* <html ...><body ...>line1<BR/>line2</body></html> gajim показывает ОДНУ строки вместо двух

Проще говоря, gajim отображает неверно все XHTML-IM сообщения, даже свои собственные.

И это простые примеры обычных ежедневных сообщений. А если делать «по стандарту», а не «по XML-консоли», то придётся учитывать, что <p><p><p>text</p></p></p> — это одна строка, а <p><p></p><p>text</p></p> ­— две строки (хотя и тут спорный вопрос).

В отличие от gajim-а pidgin хотя бы поддерживает его правильно для обычных сообщений. Gajim даже этого не делает.

Если они умеют читать, то сами поймут, в чём проблема

Пока что даже я не понимаю, в чём проблема. Направления перевода по указанной ссылке xmpp:translate.jrudevels.org я вижу, указывать их могу. Ладно, хрен с ней, со статьёй, можно хотя бы увидеть Steps to Reproduce? Не отмазки в стиле «сами разберутся», а нормальную доступную англоязычным пользователям пошаговую инструкцию воспроизведения проблемы?

нельзя удалённо управлять своими клиентами и своими серверами. [...] XEPы. Названия клиентов и серверов с remote control.

Можно (скриншот adhoc-команд psi, скриншот управления ejabberd) и очень давно. Поэтому я и прошу статью или пошаговую инструкцию.

У всех есть баги. Я использую гаджим очень плотно каждый день, в том числе, и в разработке. И, в отличие от пиджина, проблем не вижу

См.выше, примеры xhtml-im. :) Да и как можно не заметить, что gajim не может получить список конференций?

Ничего не имею против пиджина как комбайна, но говорить, что он хорош для xmpp пока рано. Да блин, какой хороший клиент не показывает статусы пользователей в MUC?

Этого не хватает, да. Был даже патч под старую версию где-то. Но автор его забросил, а больше никто не подобрал. Зато в pidgin-е прямо в тексте конференции видно, если автор сообщения уже ушёл.

Так может наоборот, стоит убрать <P> из стандарта, как никому не нужный? Всё равно стандарт — draft, и есть BR.

Лол. Ну иди напиши об этом в XSF, посмеёмся вместе.

Думаю, параграфы не используют потому, что легко нарваться на баг вроде <p>text<b>is</p><p>bold</b></p>

Как блин в протоколе, базирующемся на XML можно наткнуться на баг в невалидном XML? Ты что-то загнул тут совсем.

которое можно встретить в HTML

Это не валидно и в HTML. Тема медленно начинает приближаться по полезной информации к той, где парень говорил, что GIFы это плохо.

И даже если учесть такие случаи, параграфы всё равно трудно поддерживать.

Не можешь — не поддерживай (весь XEP). Простое правило, которое многим облегчит жизнь.

Тот же gajim делает это криво даже в обычных сообщениях

Ты говоришь «обычные», а примеры приводишь XHTML... странно, не?

<html ...><body ...><p>text</p></body></html> gajim показывает две строки вместо одной

Это ложь.

<html ...><body ...><p>line1<br/>line2</p></body></html> gajim показывает три строки вместо двух

Это тоже ложь.

<html ...><body ...>line1<BR/>line2</body></html> gajim показывает ОДНУ строки вместо двух

Ну вы поняли...

Надеюсь, мне зачтётся то, что я не поленился и всю эту брехню проверил. Версия гаджима: Gajim 0.15, из последней убунты.

И это простые примеры обычных ежедневных сообщений. А если делать «по стандарту», а не «по XML-консоли», то придётся учитывать, что <p><p><p>text</p></p></p> — это одна строка, а <p><p></p><p>text</p></p> ­— две строки (хотя и тут спорный вопрос).

Таких упоротых конфигураций пока никто не просил. К тому же, это вообще не валидный XHTML, может хватит выдумывать?

В отличие от gajim-а pidgin хотя бы поддерживает его правильно для обычных сообщений. Gajim даже этого не делает.

Опять твои фантазии.

Пока что даже я не понимаю, в чём проблема. Направления перевода по указанной ссылке xmpp:translate.jrudevels.org я вижу, указывать их могу. Ладно, хрен с ней, со статьёй, можно хотя бы увидеть Steps to Reproduce? Не отмазки в стиле «сами разберутся», а нормальную доступную англоязычным пользователям пошаговую инструкцию воспроизведения проблемы?

Мне надоело, ты уже скатился в троллинг. Прочитай статью что ли, там всё написано. XEP по ad-hocу тоже вполне понятен, какие steps-to-reproduce? Это не баг, это не реализованный XEP.

Можно (скриншот adhoc-команд psi, скриншот управления ejabberd) и очень давно. Поэтому я и прошу статью или пошаговую инструкцию

А вот тут спасибо за информацию, значит adhoc есть, только не в полном объёме (из дискавери не выполнить).

Поэтому я и прошу статью или пошаговую инструкцию.

Добавить в ростер translate.jrudevels.org и попробовать сделать перевод через adhoc. Если получится, претензия только одна: про невозможность выполнить из дискавери.

Да и как можно не заметить, что gajim не может получить список конференций?

Ты не поверишь! %)

Зато в pidgin-е прямо в тексте конференции видно, если автор сообщения уже ушёл.

Это как?

Как блин в протоколе, базирующемся на XML можно наткнуться на баг в невалидном XML? Ты что-то загнул тут совсем.

Блин, ты издеваешься? Да, если сообщение пришло, то оно обычно валидно. Но если ты его отправляешь, то позаботиться о его валидности — твоя проблема. Поэтому отправляющему приходится учитывать эту проблему, чтобы не натолкнуться на этот баг. В случае <BR> баги не будет, а в случае <P> — будет. Потому никто и не морочит себе голову с P — чтобы не бороться с лишними багами.

Ты говоришь «обычные», а примеры приводишь XHTML... странно, не?

«Обычные» — это не те, в которых нет разметки, а те, которые отправляются каждый день обычными пользователями через обычные клиенты. То есть не редкие уникальные случаи, а сообщения из обычной жизни.

Это ложь. [...] Это тоже ложь. [...] Ну вы поняли...

Пруфскрин. В общем, это правда, и то тоже правда, ну мы понели. Всё тот же gajim 0.15.2.

В отличие от gajim-а pidgin хотя бы поддерживает его правильно для обычных сообщений. Gajim даже этого не делает.

Опять твои фантазии.

Так что там про фантазии?

Надеюсь, мне зачтётся то, что я не поленился и всю эту брехню проверил.

Угу, и мне поднятие ejabberd, установку последних pidgin-а, gajim-а и psi, скриншоты пруфов и терпеливые попытки вытащить нормальный багрепорт.

Таких упоротых конфигураций пока никто не просил.

Вообще-то кто-то тут заявлял про реализацию «не по XML-консоли»...

К тому же, это вообще не валидный XHTML, может хватит выдумывать?

В каком месте он невалидный? И это не я выдумываю. Я всего лишь прошу внятный багрепорт по pidgin-у, такой, который не стыдно было бы запостить в багзиллу. А о том, что в gajim-е реализация xhtml-im хромает даже на собственных сообщениях — это было всего лишь к слову о том, что в pidgin-е xhtml-im один из самых адекватных.

А вот тут спасибо за информацию, значит adhoc есть, только не в полном объёме (из дискавери не выполнить).

Не в полном? Чего не хватает? (из дискавери его не удобно выполнять, да XEP и не требует выполнять его оттуда)

Добавить в ростер translate.jrudevels.org и попробовать сделать перевод через adhoc.

То, что перевод делается через adhoc должно как-то по-особенному проявляться? Кроме этого сервиса ещё в каких-то случаях можно увидеть баг?

Ты не поверишь! %)

Чему не поверю? Тому что можно не заметить явный баг? Отчего же, поверю, у фанатов это вообще сплошь и рядом. Как говорится, в чужом глазу...

Это как?

Имя выделяется курсивом в тексте.

Блин, ты издеваешься? Да, если сообщение пришло, то оно обычно валидно. Но если ты его отправляешь, то позаботиться о его валидности — твоя проблема. Поэтому отправляющему приходится учитывать эту проблему, чтобы не натолкнуться на этот баг. В случае <BR> баги не будет, а в случае <P> — будет. Потому никто и не морочит себе голову с P — чтобы не бороться с лишними багами.

Нет, издеваешься тут ты, т.к. даёшь невалидный XML, который не пропустит сервер, и всего делов.

В общем, это правда, и то тоже правда, ну мы понели. Всё тот же gajim 0.15.2.

Я своим глазам верю больше. Если в новых версиях что-то сломали, напиши багрепорт, могу завтра перепроверить на генте, если повторится, напишу даже сам. Но суть в том, что если такой баг и есть, он временный, а в стабильных версиях всё ок.

Угу, и мне поднятие ejabberd, установку последних pidgin-а, gajim-а и psi, скриншоты пруфов и терпеливые попытки вытащить нормальный багрепорт.

Пока ты не перестанешь называть фичрекветы багрепортами, я эту тему обсуждать отказываюсь.

Вообще-то кто-то тут заявлял про реализацию «не по XML-консоли»...

Я заявлял и заявляю, что те примеры, что ты даёшь не валидны, проверь валидатором.

В каком месте он невалидный? И это не я выдумываю. Я всего лишь прошу внятный багрепорт по pidgin-у, такой, который не стыдно было бы запостить в багзиллу. А о том, что в gajim-е реализация xhtml-im хромает даже на собственных сообщениях — это было всего лишь к слову о том, что в pidgin-е xhtml-im один из самых адекватных.

Блин, да вбей ты уже в валидатор эти несчастные три строчки и убедись, что такого XHTML быть не может, а? Ну хватит уже цирк тут разводить.

XHTML без параграфов называть адекватным, это ну я не знаю, как минимум, не адекватно.

Не в полном? Чего не хватает? (из дискавери его не удобно выполнять, да XEP и не требует выполнять его оттуда)

Скользская тема, так что я перефразирую: как в pidginе выполнить команду у сущности, которой нет в твоём ростере?

То, что перевод делается через adhoc должно как-то по-особенному проявляться? Кроме этого сервиса ещё в каких-то случаях можно увидеть баг?

Я устал, я не могу больше на это отвечать, разуй глаза, поставь другой клиент (да хоть ткаббер).

Чему не поверю? Тому что можно не заметить явный баг? Отчего же, поверю, у фанатов это вообще сплошь и рядом. Как говорится, в чужом глазу...

УМВР. ЧЯДНТ? jabber.ru запросил конфы за пару секунд. убунту.

Имя выделяется курсивом в тексте.

Сомнительная фича, но, думаю, если сильно надо, в гаджиме без проблем запилят.

даёшь невалидный XML, который не пропустит сервер, и всего делов.

Именно, что не пропустит. Поэтому, если клиент (или бот, или какой-то другой сервис) хочет использовать <P>, ему придётся проверять сообщение, и специальным образом отслеживать и обрабатывать подобные баги. С BR такой проблемы нет, имхо, поэтому P никто не использует. Или таки использует?

Я своим глазам верю больше. [...] Но суть в том, что если такой баг и есть, он временный, а в стабильных версиях всё ок.

Не, это не новый баг. Отправь самому себе через XML-консоль то сообщение, и убедишься.

Пока ты не перестанешь называть фичрекветы багрепортами, я эту тему обсуждать отказываюсь.

Если фичреквест записывается в багтрекер — он не считается багрепортом? Ладно, пусть будет фичреквест. Значит я терпеливо пытаюсь вытянуть фичреквест по adhoc и багрепорт по параграфам.

Я заявлял и заявляю, что те примеры, что ты даёшь не валидны, проверь валидатором.

Можно ссылку на валидатор, который посчитает те примеры невалидными?

XHTML без параграфов называть адекватным, это ну я не знаю, как минимум, не адекватно.

Чем XHTML без параграфов (без тега P, если точнее) хуже, например, XHTML-я без DIV-ов?

как в pidginе выполнить команду у сущности, которой нет в твоём ростере?

Добавить в ростер, я полагаю. :)

УМВР. ЧЯДНТ? jabber.ru запросил конфы за пару секунд. убунту.

А теперь запроси их у jabber.org.

Именно, что не пропустит. Поэтому, если клиент (или бот, или какой-то другой сервис) хочет использовать <P>, ему придётся проверять сообщение, и специальным образом отслеживать и обрабатывать подобные баги.

Это настолько бредовый аргумент, что я промолчу. Ты, видимо, из тех, кто генерит XML конкатенацией.

С BR такой проблемы нет, имхо, поэтому P никто не использует. Или таки использует?

Не знаю, меня это вообще мало волнует. Мне надо, чтоб если я вижу в features xhtml, то рендерилось ожидаемо. А то получается, что как с браузерами, для каждого нужны свои костыли. Только вот тут [if IE lt9] не напишешь, видишь ли.

Не, это не новый баг. Отправь самому себе через XML-консоль то сообщение, и убедишься

Я, по-твоему, как это проверял? :)) Буду на генте, перепроверю, и могу даже выслать скриншот заверенный XML-логом.

Если фичреквест записывается в багтрекер — он не считается багрепортом? Ладно, пусть будет фичреквест. Значит я терпеливо пытаюсь вытянуть фичреквест по adhoc и багрепорт по параграфам.

Ну здесь я наверно чутка психанул. Вопрос сейчас в том, как вызвать команды у сущности не в ростере.

Можно ссылку на валидатор, который посчитает те примеры невалидными?

Какие _те_? Те три примера валидны и гаджимом обрабатываются правильно. Невалиден пример с тремя вложенными параграфами, и проверить ты это можешь валидатором на w3.org

Чем XHTML без параграфов (без тега P, если точнее) хуже, например, XHTML-я без DIV-ов?

Тем, что отсутствие поддержки DIV-ов можно ожидать, а отсутствие поддержки параграфов как-то не очень. Но, в целом, я соглашусь в том, что кастрированная (т.е. поддержка не всех тегов, описанных в XEP, а только рекоммендуемых) поддержка немногим лучше такой как в пиджине, ибо один фиг сделать так, чтобы смотрелось нормально везде почти невозможно. Это минус в сторону XSF, и, наверно, я даже сочиню по этому поводу письмо в рассылку, и этот трёп можно будет считать не совсем бесполезным.

Добавить в ростер, я полагаю. :)

Сервис не обязан себя дать добавить. Что дальше? А если мне надо один раз выполнить и забыть? Добавлять-удалять?

А теперь запроси их у jabber.org.

<iq xmlns="jabber:client" to="conference.jabber.org" type="get" id="3890">
<query xmlns="http://jabber.org/protocol/disco#items" />
</iq>

И тишина. Сервер не соответствует не то, что XEP, он RFC не соответствует, а виноват, конечно, gajim.

Пытался зарегить аккаунт на jabber.org, чтобы исключить возможное влияние резалок станс по размеру, но, увы, не вышло.

Кстати, хз, что я делаю не так, но в моём пиджине команды не появляются и в контекстном меню в ростере. Не подскажешь, как их включить?

поэтому P никто не использует. Или таки использует?

Jappix.

Именно, что не пропустит. Поэтому, если клиент (или бот, или какой-то другой сервис) хочет использовать <P>, ему придётся проверять сообщение, и специальным образом отслеживать и обрабатывать подобные баги. С BR такой проблемы нет, имхо, поэтому P никто не использует. Или таки использует?

Вот тут ты оказался прав, внезапно. :) Зашлю гаджиму патч, как-нибудь, чтобы это исправить.

Вообще, я никогда не отрицал, что код у гаджима местами ну не очень кошерен. Однако же, из jabber-клиентов пока ничего лучше не знаю. :(

Пруфскрин.

А, понял, почему разные результаты у нас. По первым двум случаям: там одна и две строки, то что там есть отступ, это результат того, что у параграфа есть дефолтные стили, у которых прописан margin. Это НЕ отдельная строка, это просто css.

По поводу третьего случая, там опять невалидный XHTML (ну сколько можно то?), там должно быть <br/>, а не <BR/>, да xml чувствителен к регистру, в отличие от SGML.