Public interface for serializers

[tmichela]

This moves the serializer implementation from extra-data, the aim is to allow 3rd party tools to use it (as requested by @zhujun98 ).

Along the way:

• use the same implementation in the simulation code (will update in extra-data when this is released)
• support dummy timestamps for protocol version 1.0
• fix: do not modify input dict (data and metadata). There were modified in 2 cases:
  • use of dummy timestamps
  • in version 1, metadata was copied into data

from karabo_bridge import serialize, deserialize

d, m = deserialize(serialize(data, metadata))

[zhujun98]

In general LGTM from my side. The new serialize implementation is almost a mirror of https://github.com/European-XFEL/EXtra-data/blob/master/extra_data/export.ZMQStreamer._serialize`.

Thanks for implementing this. I will use it in EXtra-foam, particularly for the extension.

[tmichela]

The new serialize implementation is almost a mirror of

Yes, that's the idea. I will then update extra-data to use this version

[takluyver]

LGTM.

One small API question: there are a couple of configuration parameters (protocol_version, dummy_timestamps) which are likely to be the same for many calls. Maybe it would be useful to have a serialiser class which would take those arguments and have a .serialise() method, separating input and configuration. But to be honest, I probably wouldn't bother for just 2 parameters, and we can always add it later if we want more options.

[zhujun98]

I am also in favor of class.

[tmichela]

Hum, I originally wrote a class, but I found a bit silly seeing a class with a single method and a single argument, so I changed it... And especially because the arguments are mostly there for backward compatibility. I believe that nobody will ever use the version 1.0 and the fake timestamps won't make sens once we use the timestamp from the hdf5 files...

I personally prefer having a simple function, but if you both prefer a class, I can change it back

[takluyver]

With just these two config parameters, I'd probably leave it as a single function, but I don't have a strong preference either way.

[tmichela]

Thanks both for the review. I'll then leave it as functions. This can changed it it becomes more customizable...