@ugnich, проверка

@LL1ypuk, Проверка

@FGNTFG, Пользователям ja глубоко фиолетово на новые извращения

@ugnich, А что изменилось?

@Santiago26, Внешне — практически ничего. Внутри всё переписано, чтобы постинг больше никогда не "отваливался".

@ugnich, Ник того, кому я отвечаю в коментах не появится?

@ugnich, А ники почему пропали? Не то чтоб меня это особо волновало, но все-таки

@GOOD-Ron, Нет.

@ugnich, Расскажи, пожалуйста, какими мотивами ты руководствовался, убирая ники?

@kapsh, Это вызывало падения (инфа 100%)

@kapsh, Самыми наилучшими.

@ugnich, Картинку в этом комментарии не было видно через жаббер — juick.com

@vt, В ПРИВАТ, ПОЖАЛУЙСТА

@ugnich, Что может быть лучше слома половины клиентов? Ну это не говоря уже про невозможность нормального чтения через веб. Убирание ников имеет смысл для веба, причем в режиме дерева, зачем их убирать во всех остальных случаях?

@ugnich, Не ори.

@vt, Что значит "слом клиентов"? о_О Кто-то писал плагины с захардкоженным шаблоном парсинга? Тогда какие претензии к сервису? Кто хардкодил — тот и дурак. Psi, QIP — УМВР.

@Santiago26, Специально чтоб не искать ник в теле сообщения, просили раньше в API присылать признак того, что это сообщение личное, чтоб клиент мог уведомлять только на личные ответы, а срачи тихо пропускать. И это даже работало. Потом оказалось, что XMPP API "устарел", и этот признак убрали, пришлось вернуться к поиску ника. Ну а щас и отображение ника устарело.
А в HTTP API этого признака вообще никогда не было, впрочем как и уведомлений.

@vt, Не, XMPP API в части <juick > в <message > ещё вроде как не устарел, убрали только iq-запросы. Но атрибут reply-to-you из <juick /> таки убрали, да. С отменой iq’шек тоже есть проблемы — если несколько Juick-аккаунтов подключены через j2j, то корректно определить свой ник или id для данного элемента ростера затруднительно.

@Totktonada, Не хватает whoami

@FGNTFG, Оно есть через HTTP-API, но для реализации схемы выше через него надо узнавать свой JID от j2j. Как это сделать, я не знаю.

@Totktonada, ну щас даже если определить свой ник, то по сообщению вообще никак не узнаешь что оно личное. Только если строить полностью дерево ответов чрез replyto и там искать ник.

@vt, Не надо полностью. Просто иногда пришлось бы запрашивать дополнительно сообщения и кэшировать их. Потерпеть тормозную индикацию.

@Totktonada, послать ему jabber:iq:register и поискать в полученной форме

@vt, Ага. Но теперь проще выпилить индикацию ответов.

@Totktonada, Такие обсуждения мне по душе. Скажите, что я могу для вас сделать?
К сожалению, в силу особенностей архитектуры, высылать каждому подписчику индивидуальные уведомления (c/без replytoyou) будет очень сложно (читай: плохой вариант), поэтому хотелось бы найти другое решение. Какие есть варианты?

@ugnich, а как это касается подписчиков? Это касается разработчиков только.

@ugnich, Можно высылать в сообщении ник или id того, ответом на чьё сообщение является комментарий? Например, replytouser=1 для этого сообщения.

@Totktonada, Окей, допустим. Что это даст? Какие клиенты/плагины смогут внести эти изменения?

@ugnich, Tkabber.

@Totktonada, Найдите Tkabber в списке популярных Jabber клиентов: juick.com
Если только Tkabber, то оно того не стоит, извините.

@ugnich, BombusMod.
Но получается — нормальный апи не нужен, потому что никто не пользуется, а никто не пользуется, потому что нет нормального апи.

@vt, АПИ ничего не изменит в плане популярности.

@ugnich, То есть последними изменениями, по вашему, не была сломана поддержка Juick в Psi+? github.com

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

@Totktonada, Поддержка не была сломана, её просто нету для новой фичи "указывать ссылки в маркдауне".

@Santiago26, Н-да, я имел в виду предпоследнее изменение, о котором здесь до того и говорили. Впрочем, из строки 36 по приведённой ссылке это очевидно.

@Totktonada, Во-первых, давайте от этого обиженного тона вернемся к нормальному конструктивному обсуждению.
Во-вторых, при всём моем уважении и со всей благодарностью к Khryukin Evgeny, но парсить текстовые ответы бота, при наличии данных в XML — это говнокод.

@ugnich, 1. Да, можно было с самого начала акцентировать внимание на фичах, а не популярности клиентов.
2. Когда писался плагин для Tkabber’а, XMPP-API ещё не было. Насчёт Psi+ не знаю. Впрочем, на этот сделанный со всей благодарностью выпад я, пожалуй, отвечать не буду. Давайте вернёмся к конструктивному обсуждению: «парсить текстовые ответы бота, при наличии данных в XML…» — будут необходимые данные в XML или нет? Возможность парсить-то уже убрали.

@Totktonada, Большинство необходимых данных уже есть в XML всех сообщений приходящих по подписке. Кто их парсит? Ради кого нужно что-то добавлять?
Я думаю, что нужно ещё раз провести собрать статистику популярности клиентов и уже от неё отталкиваться. У меня есть подозрение, что абсолютное большинство людей пользуются клиентами, для которых это изменение API будет совершенно бесполезно.