Hi there @dreamoka , sorry for the delay, I had to confirm some stuff with R&D and do some testing myself.
So the short answer is: kind of. More below.
This feature was primarily built for SMF-to-SMF applications, specifically for 3rd-party JMS apps that don’t really do “coding” and more just set properties on their connections. Implementing payload compression yourself in code is actually pretty trivial… this is for apps that are very hands-off!
So: an AMQP (or MQTT) client *receiving * a message from a payload-compressed-enabled SMF client, it would be possible for it to simply check the Content Encoding is deflate and then inflate the payload using standard mechanisms. For example, it would look something like this in Java:
Inflater inflater = new Inflater();
ByteArrayOutputStream os = new ByteArrayOutputStream();
try {
inflater.setInput(bytes);
byte[] buffer = new byte[1024];
while (!inflater.finished()) {
int decompressedSize = inflater.inflate(buffer);
os.write(buffer, 0, decompressedSize);
}
bytes = os.toByteArray();
} catch (DataFormatException e) {
logger.warn("Had a message marked as 'deflate' but wasn't");
} finally {
try {
os.close();
} catch (IOException e2) { }
}
However, the other direction is not possible… having an AMQP client sending a compressed payload (even with the correct Content Encoding set) and have it automatically inflated won’t work. There are some magic bits set by the API that it needs to automatically inflate. But, the receiving app could do the exact same checks above and inflate it manually.
Again, implementing payload compression yourself isn’t hard…. just ~15 lines of code. This feature was mainly introduced for those customers that don’t like coding.