Dvl/klaus/webadm readable msg

[klausfmh]

The goal is to have adapt the web interface such, that the messages that are posted are a little better readable.

[jrmi]

Review not yet finished.

[jrmi]

Why this is not a Message method ?

[feenes]

Each channel handles different kinds of messages.
I imagine the usecase where a channel wants to have a different representation of a message.

Let's say an MLLP channel would prefer to have perhaps a partially preparsed representation for the web interface,
A file watcher channel might not display the contents of the file, but more stats about the file.

An alternative would of course be to put this method into the channel and let certain endpoints / channels subclass the Message object. (Though this might imply more data copies)

[jrmi]

Seems fair.

New proposal : you add the method to the Message class but you allow to redefine default payload_encoder with an argument. Then you add a method to the channel that call the Message method with the appropriate encoder. Later (i.e. in another PR) we can add a way to custom encoder by a channel argument.

What do you think ?

I think you can use current .to_dict() method and add the correct argument to achieve that ?

[jrmi]

After more thinking, more details :

• You can create two messages serializer (at least) in the serializer file : b64picklerEncoder and JsonableEncoder,
• Add payload_encoder option to Message.to_json() method with b64picklerEncoder as default encoder (to keep compatibility) and propagate the option to .to_dict() method,
• Add a message_payload_encoder property to channel with b64 default encoder with default value to b64encoder,
• Use this encoder in the .list_message() while calling .to_json() to get your formatted message.

Do I miss something ?

[feenes]

should the param for message_payload_encoder be
a class, an instance (which must have the method encode or just a function that encodes).

Will make a first start with an instance, but I am open.

and the more I think the less I wonder why not just passing a function, except we want to group the encode and decode function in the same office.

In that case we should perhaps call the param
payload_codec.

[klausfmh]

My bad. pushed only to local gitlab server and not to github

Just check klausfmh@297b219

[klausfmh]

In fact best to recheck all the deltas of this MR

[feenes]

reminder to continue review :-)
I think I handled all the FB. pls correct me if wrong

[jrmi]

Yes that's what i think for message but part :

• Add a message_payload_encoder property to channel with b64 default encoder with default value to b64encoder,
• Use this encoder in the .list_message() while calling .to_json() to get your formatted message.

is not yet done ?

[jrmi]

I think jsonable_msg_info_for_admin channel method should not exists anymore at the end.

[jrmi]

What if we create an payload_serializer param that can be what we want ? The default one is a b64pickle, but we can specify the "jsonable" one ?

[klausfmh]

That's an option.

Another one would be to just pass a 'name' of a serializer and allow to register other ones if desired.

[klausfmh]

what to do?

[jrmi]

Agree with your proposal.

[jrmi]

Again, why is this not a message method ?

[klausfmh]

see comment above