-
juick.comОбновлен постинг сообщений и комментариев через сайт. Если у вас возникнут любые проблемы, пожалуйста пишите мне лично в приват или сюда:
Писать о проблемах с сервисом себе в блог, в комментарии или на деревню дедушке не стоит, потому что ваше сообщение я, скорее всего, не увижу.♡ recommended by @Ta2i4
Replies (38)
-
@Santiago26, Внешне — практически ничего. Внутри всё переписано, чтобы постинг больше никогда не "отваливался".
-
@vt, Что значит "слом клиентов"? о_О Кто-то писал плагины с захардкоженным шаблоном парсинга? Тогда какие претензии к сервису? Кто хардкодил — тот и дурак. Psi, QIP — УМВР.
-
@Santiago26, Специально чтоб не искать ник в теле сообщения, просили раньше в API присылать признак того, что это сообщение личное, чтоб клиент мог уведомлять только на личные ответы, а срачи тихо пропускать. И это даже работало. Потом оказалось, что XMPP API "устарел", и этот признак убрали, пришлось вернуться к поиску ника. Ну а щас и отображение ника устарело.
А в HTTP API этого признака вообще никогда не было, впрочем как и уведомлений. -
@vt, Не, XMPP API в части <juick > в <message > ещё вроде как не устарел, убрали только iq-запросы. Но атрибут reply-to-you из <juick /> таки убрали, да. С отменой iq’шек тоже есть проблемы — если несколько Juick-аккаунтов подключены через j2j, то корректно определить свой ник или id для данного элемента ростера затруднительно.
-
@FGNTFG, Оно есть через HTTP-API, но для реализации схемы выше через него надо узнавать свой JID от j2j. Как это сделать, я не знаю.
-
@Totktonada, ну щас даже если определить свой ник, то по сообщению вообще никак не узнаешь что оно личное. Только если строить полностью дерево ответов чрез replyto и там искать ник.
-
@vt, Не надо полностью. Просто иногда пришлось бы запрашивать дополнительно сообщения и кэшировать их. Потерпеть тормозную индикацию.
-
@Totktonada, послать ему jabber:iq:register и поискать в полученной форме
-
@Totktonada, Такие обсуждения мне по душе. Скажите, что я могу для вас сделать?
К сожалению, в силу особенностей архитектуры, высылать каждому подписчику индивидуальные уведомления (c/без replytoyou) будет очень сложно (читай: плохой вариант), поэтому хотелось бы найти другое решение. Какие есть варианты? -
@ugnich, Можно высылать в сообщении ник или id того, ответом на чьё сообщение является комментарий? Например, replytouser=1 для этого сообщения.
-
@Totktonada, Окей, допустим. Что это даст? Какие клиенты/плагины смогут внести эти изменения?
-
@Totktonada, Найдите Tkabber в списке популярных Jabber клиентов: juick.com
Если только Tkabber, то оно того не стоит, извините. -
@ugnich, То есть последними изменениями, по вашему, не была сломана поддержка Juick в Psi+? github.com
Нет, при таком подходе действительно проще потихоньку выпиливать фичи, чем восстанавливать их работу после каждого переосмысления вами архитектуры. -
@Totktonada, Поддержка не была сломана, её просто нету для новой фичи "указывать ссылки в маркдауне".
-
@Santiago26, Н-да, я имел в виду предпоследнее изменение, о котором здесь до того и говорили. Впрочем, из строки 36 по приведённой ссылке это очевидно.
-
@Totktonada, Во-первых, давайте от этого обиженного тона вернемся к нормальному конструктивному обсуждению.
Во-вторых, при всём моем уважении и со всей благодарностью к Khryukin Evgeny, но парсить текстовые ответы бота, при наличии данных в XML — это говнокод. -
@ugnich, 1. Да, можно было с самого начала акцентировать внимание на фичах, а не популярности клиентов.
2. Когда писался плагин для Tkabber’а, XMPP-API ещё не было. Насчёт Psi+ не знаю. Впрочем, на этот сделанный со всей благодарностью выпад я, пожалуй, отвечать не буду. Давайте вернёмся к конструктивному обсуждению: «парсить текстовые ответы бота, при наличии данных в XML…» — будут необходимые данные в XML или нет? Возможность парсить-то уже убрали. -
@Totktonada, Большинство необходимых данных уже есть в XML всех сообщений приходящих по подписке. Кто их парсит? Ради кого нужно что-то добавлять?
Я думаю, что нужно ещё раз провести собрать статистику популярности клиентов и уже от неё отталкиваться. У меня есть подозрение, что абсолютное большинство людей пользуются клиентами, для которых это изменение API будет совершенно бесполезно.