Имеется ввиду iconv_get_encoding('all')? Если да, то по умолчанию все кодировки iconv «ISO-8859-1», но я выставлял их и в 1251 и utf-8. Брокер ни на что не матерится, он молча пишет в базу и также молча выдает, но вот начинаю припоминать что про кодировку MySQL я забыл, возможно она тоже приложила руку к этому. Брокер — Apache ActiveMQ.
Я пробовал и убирать это из заголовка и принудительно вписывать туда UTF-8, сейчас еще раз это проверил — не выходит, если скармливать XML напрямую боту, то никаких плясок не нужно, но если отправлять его через брокер, с этим сообщение происходит что-то непонятное и я только экспериментальным путем смог установить последовательность перекодировок которая выдала нужный результат. Но возможно я что-то упустил и есть более простой вариант решения этой проблемы.
2-3 падения в год для меня не фатально, все таки не на АЭС работаю, проблемы с кодировкой возникли после введения ActiveMQ как промежуточного звена, напрямую все прекрасно отправляется безо всяких преобразований. Неизменность протокола это да, проблема, но обычно ее довольно быстро решают разработчики сторонних библиотек.
Я не пытаюсь сказать что ХМРР никуда не годится и ICQ спасет мир, просто завязать это все на аську лично для меня было проще, если бы у нас в компании все работали на mail.ru агент, я бы написал бота на его протоколе.
Если честно, то я не проверял, при моей нагрузке это и не понять. Изначально мускл я использовал для того, чтобы наглядно видеть что работает сохранение сообщений, так как с этим были некоторые трудности.
Как любят говорить в нашей компании «Так сложилось исторически», у всех сотрудников есть ICQ, протокол стабильный и проверенный временем, а поднимать локальный джаббер-сервер и включать его в эту и без того многозвенную схему как то не очень хотелось. Хотя ХМРР вполне достойная альтернатива и, возможно, кому-то будет удобней использовать именно этот протокол.
Кстати не так давно у меня была рабочая библиотека под делфи для отправки смс через агент mail.ru, самое главное она стабильно работала, хотя и с некоторыми ограничениями по частоте отправления, но я реально думал построить бота на ее основе, пока не узнал что с недавнего времени мейлрушники прикрыли возможность отправки SMS для сторонних клиентов, вот такая печаль.
Основная польза в том, чтобы не привязывать бота к определенной платформе, при использовании брокера совершенно не важно какое приложение генерирует баг-репорт, будь то PHP скрипт в он-лайн части или же десктопное приложение на Delphi/C#/.NET, механизм взаимодействия с ботом будет единым — просто отправить сообщение в очередь на MQ. Еще один плюс — при большом количестве генерируемых сообщений можно запустить одновременно несколько ботов, а распределением заданий между ними будет заниматься ActiveMQ. Также можно в плюсы занести возможность хранения сообщений при невозможности их мгновенной отправки, но в рамках данной темы это не очень актуально.
Почта приходит и почта уходит немного разные вещи, какой бы шустрый не был гугл, если на нашем сервере собралась очередь из писем на отправку, то он бессилен. Но согласен, в плане реализации оповещение на почту в разы проще.
Имеется ввиду когда сервер ICQ начинает блокировать подключения после обрыва связи? Если да, то такой проблемы у меня не было, но на этот случай имеется прогрессивный таймаут при реконнектах, так что рано или поздно бот с сервером свяжется.
SMS дороже, если использовать нормальный шлюз, да и насчет скорости большой вопрос, ICQ сообщения доставляется за секунды, а вот смски порой минутами в очередях у операторов стоят.
Почта не всегда доставляется мгновенно, да и в случае какого-нибудь прорыва может сильно заспамить и провайдер закроет порт. Тем более мне не нужно хранить историю, она вся хранится на сервере вместе с дампами ошибок, здесь мне нужно просто узнать о самом факте возникновения ошибки.
Я не пытаюсь сказать что ХМРР никуда не годится и ICQ спасет мир, просто завязать это все на аську лично для меня было проще, если бы у нас в компании все работали на mail.ru агент, я бы написал бота на его протоколе.