provide a serializer behaviour, default v1&v2 implementations

[the-mikedavis]

see #26

JSON is a good default but it's not the only encoding method out there. Phoenix supports arbitrary encoding schemes with its Phoenix.Socket.Serializer behaviour.

Slipstream should provide a similar behaviour and allow one to pass a module which implements the behaviour as configuration. We should be able to write a custom parser in Slipstream.Configuration that validates that a :serializer key implements the behaviour.

(Say we provide c:Slipstream.Serializer.encode!/1 and c:Slipstream.Serializer.decode!/2, we should be able to write a function that works with NimbleOptions by comparing proposed_module.__info__(:functions) with Slipstream.Serializer.behaviour_info(:callbacks))

Default implementations should also match Phoenix's:

• https://github.com/phoenixframework/phoenix/blob/38b3702fd4/lib/phoenix/socket/serializers/v1_json_serializer.ex
• https://github.com/phoenixframework/phoenix/blob/38b3702fd4/lib/phoenix/socket/serializers/v2_json_serializer.ex

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nathanl]

I'm not sure if this belongs on this issue, but it's related to Slipstream's data serialization. Channel supports binary data: def handle_in("file_chunk", {:binary, chunk}, socket) do. This is used in the JS upload client to send a chunk of a file at a time. As far as I can tell, Slipstream requires any payload to be a JSON-encodable map, so binary data has to be string encoded (eg Base.encode64/1), which increases its size.

[the-mikedavis]

Ah I think we could use the same syntax for that. I think that binary chunks are not touched by the serializer/deserializer though - just sent as-is as WebSocket binary frames - so I will open a separate issue for that

[the-mikedavis]

Let's call this closed with the serializer configuration and V2 JSON default serializer added in #56 (v1.1.0). The V1 serializer is quite old so maybe we can get away with not adding a built-in module for that.