Another proposal would be to always use addslashes/stripslashes on the serialized payload.
That would allow removing the option - ie less complexity. WDYT?

Another proposal would be to always use addslashes/stripslashes on the serialized payload.
That would allow removing the option - ie less complexity. WDYT?

I think thisdoes fix the problem. It would not allow message objects themselves to contain binary data, but probably that's not supported? Here is what SQS says about character sets:

A message can include only XML, JSON, and unformatted text. The following Unicode characters are allowed:

#x9 | #xA | #xD | #x20 to #xD7FF | #xE000 to #xFFFD | #x10000 to #x10FFFF

Is addslashes sufficient?

That would allow removing the option - ie less complexity. WDYT?

I don't like this option. I often copy/paste message from/to AMQP. More over I often have different language between my producer and my consumer. (But I'm not sure the messenger component is designed for such use cases).

Instead of an option, why don't you addTransport::needEscaping() ?

I often copy/paste message from/to AMQP.

What's the format you usually use? serialized PHP or JSON?

More over I often have different language between my producer and my consumer. (But I'm not sure the messenger component is designed for such use cases).

It absolutely is. But in that case, you'd be using the Symfony serializer (JSON) or something custom. Indeed the PhpSerializer is (mostly) only for the situation where you plan to send and consume from your Symfony app.

Instead of an option, why don't you add Transport::needEscaping() ?

That's an interesting idea. In fact, the transport is responsible for calling the serializer... and so it could even pass this as an option toencode() anddecode()

It would not allow message objects themselves to contain binary data

addslashes encodes\0,'," and\

More over I often have different language between my producer and my consumer

then you're not using the PhpSerializer - my comment applies only to it.

we could also and/or alternatively define a newmessenger.transport.base64_encoded_php_serializer service instead of adding a new option

we could also and/or alternatively define a new messenger.transport.base64_encoded_php_serializer service instead of adding a new option

I like this way.

Instead of an option, why don't you add Transport::needEscaping() ?

On 2nd thought, this might be hard to implement, as this whole escaping thing only applies if you're using the PhpSerializer... and the user may or may not be using it. So, it would be a weird transport option that only applies sometimes.

What's the format you usually use? serialized PHP or JSON?

JSON of course :)

Ready for review again - I've updated the description, etc. This changes to useaddslashes instead ofbase64_encode(). This only applies to the PhpSerializer.

messenger.transport.base64_encoded_php_serializer
for another PR when needed?

Yep, exactly. It's trivial anyways - you could even decorate thePhpSerializer

Ready to go!

Thank you@weaverryan.