смотрите что получается
Вводная раз
сообщения через RMQ - это строки
протоколом описываются 2 свойства - ТипКонтента, КодировкаКонтента
Тип контента: XML, JSON
Кодировка: UTF-8, CP1251
НО - согласно протоколу, в принципе в сообщении может быть бинарные данные (base64)
Вводная два
RabbitMQ очень любит маленькие сообщения, хотя он еще любит разные другие параметры (no-ack) и т.д.
https://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/
Вводная три
Большинство 1С специалистов не любят события, а любят большие объекты, и желательно со ссылками на другие объекты - то есть большие XML
У питонистов есть библиотека Kombu (https://kombu.readthedocs.io/en/latest/userguide/producers.html#reference)
Она имеет хитрый параметр при отправке compression - то есть сжимать ли сообщение
Как он работает - он добавляет пользовательский (не протокольный заголовок)
headers: compression: application/x-gzip
Чтобы потом самому его обработать… То есть это клиентская логика, а не логика протокола AMQP
Мы можем реализовать подобное же поведение - то есть
ОтправитьСообщение(..., Сжимать = Истина)
Тогда метод ПолучитьСообщение() будет анализировать такой заголовок и разжимать сообщение на стороне компоненты
Плюсы
- сократиться объем трафика - RMQ будет передавать быстрей сообщения
- мы сможем из коробки работать с python и Django с учетом их особенностей
Минусы
- если Ваши получатели написаны на PHP. C#, ruby, etc им придется чуть дописать логику своего подписчика чтобы поддерживать указанный заголовок
P.S. 1С-2-1С допиливать не придется… Подумываю даже добавить метод Клиент.ВключитьСжатиеДляВсехСообщений(Истина);
желающие обсудить - прошу в коменты
Тогда старое не отвалится, а там, где нужно/можно - можно будет включать на уровне прикладной логики