← All posts tagged Juick

binary

juick@juick.com не возвращает ничего на iq-станс с неизвестным ему запросом, что является нарушением пункта 9.2.3 (подпункт 3) RFC 3920, нужно возвращать feature-not-implemented в таком случае. Крайне неприятный баг.

binary

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

binary

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

binary

Такой вопрос: если по факту в жуйк будет репостинг с другого блога, но формально будет наоборот (таймстамп постинга на другой блог больше, чем на жуйк), меня забанят?

binary

Обновлённая версия бекапера по старому адресу: jrudevels.org
Изменения:
* исправлена ошибка при заканчивании бекапа, теперь скрипт нормально выходит
* удалена забытая в коде зависимость от pydispatcher
* добавлены опции командной строки:
** -f — файл, в который сохранять бекап (по-умолчанию output.json)
** -v — выводить xml-лог (по-умолчанию нет)
** -q — не выводить логи (по-умолчанию да)
** -d — задержка между запросами сообщений, по-умолчанию, по-прежнему, 60 секунд, на свой страх и риск можно уменьшать (может прийти кара Угнича :)) ), бекап пойдёт гораздо быстрее.

Вот и всё, собственно. Обещанного режима неполного бекапа (а только бекапа новых сообщений) не будет, слишком геморройно работать с XMPP по Угничу, мне лень.

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

binary

Итак, как обещал, привожу свои впечатления от написания бекапера. (#1016279)
Значит, начал это писать. Вот уже оно начало парсить посты, что-то парсит в ответах, но какая-то странная проблема: если считать сумму iq с set/get и сумму с result/error, а потом вычесть из первого второе, получается отрицальное число. "WTF?!", — сказал я себе, оказывается juick может на одну iq стансу прислать хоть тысячу resultов! И, о ужас, это не баг, это фича! Как автор подразумевает хендлить их — я не понял. Хранить idшники вечно? А как высчитывать timeout? XMPP Core нигде явно не говорит, что resultов не может быть несколько (нет MUST NOT), но, я так думаю, это подразумевалось, ибо очевидно. («Thus, IQ interactions follow a common pattern of structured data exchange such as get/result or set/result») В общем, не каждая библиотека будет нормально с этим работать, я вообще не представляю, что за костыли там подразумеваются. Ок, с этим разобрался, прилепил костыль, работает. Пошли дальше.
Не помню, кто конкретно, но уже довольно давно холиварил со мной по поводу не нужности микроблогов на соотв. XEPах, мол Juick и так хорош. На мои аргументы, как с этим взаимодействовать должны люди, был ответ, что есть API и документация по нему. Ну я тогда особо разбираться не стал, заметил лишь, что оно на русском языке, и я так и вижу программистов, которые гуглтранслейтом переводят эту "документацию", на что мне сказали, мол мы английский читаем, пусть и они, ага. Ну ок, не вопрос, но проблема в том, что работу с иерархией комментариев описывать никто не собирался, и xml-консоль в помощь, ну что ж, не впервой. (Может я не там смотрю?
juick.com
Смотрим дальше: "если ваша программа регулярно запрашивает новые сообщения, при первом вызове аттрибут aftermid можно не указывать, а во всех последующих присваивайте ему значение mid последнего полученного сообщения". Сразу возникает диссонанс: сообщения запрашиваем более старые, а просим after... Ну фиг с ним, видимо, имелась в виду паджинация на сайте. Делаем, как сказано. Запускаем... Хм. Постоянно парсятся одни и те же сообщения по кругу. WTF? Попотев 20 минут, выясняем, что там, всё же, ВНЕЗАПНО, beforemid... Ок, поправили, работает.
Дошли до конца сообщений... WTF?!
В случае, если по вашему запросу нет сообщений, ответ будет следующим:





Я даже комментировать ничего не буду, я просто оставлю это здесь: xmpp.org пункт 9.3.2.

В пору писать XMPP Core Ugnich edition. О каком интероперабилити тут может идти речь, не понятно в упор. Проприетарное, не соответствуещее стандартам, централизированное. Антипод XMPP.

binary

Итак, выкладываю, как обещал, тулзу для бекапа вашего juickа: jrudevels.org
Для работы потребуется python, twisted, simplejson

Распаковываем, вводим в conf.py свой jabber-аккаунт, запускаем backup.py, ждём, бекапится по 10 сообщений в минуту, как сказано в документации по API. Для параноиков могу сказать: код открытый, закладок там нет, кому надо будет, проверят. Всё что клиент отсылает и принимает кидается в stdout.

Бекап сохраняется в текущую директорию в JSON.

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

О приключениях своих в процессе написания напишу позднее.

P.S. что побудило меня на это, в принципе, всем и так понятно, но бекапы дело хорошее для всех, я считаю.

binary

А как определяется вообще, juick — оригинальный источник или наоборот? У меня вот, например, если сначала увидеть профиль Facebook, а потом juick, можно сказать, что juick — полная копия Facebookа, притом, что в Facebook есть ещё доп информация, а в juickе только блох.

binary

Подумалось. А возможно замораживать топик через *readonly? Т.е. я начал какой-то замес, но мне надо отлучиться, я ставлю *readonly, все молчат, а потом убираю, делаю новый вброс, и всё сначала? :)) Т.е. подписчики останутся в тредике?

binary

По поводу рекомендаций: неплохо было бы сделать возможность добавить к посту что-то от себя, например: «!#123456 действительно, грустно, а у меня вот случай тоже был: ...».
Ещё есть мысль, что неплохо бы автоматически подписываться на комменты исходного сообщения, т.к. делать это отдельной командой напрягает.