Decode request reply

[edgarriba]

No description provided.

[Hackerman342]

@edgarriba the decode option in the client looks good and makes a lot of sense. But what is the advantage / use case on the service side?

[Hackerman342]

Changes to the client look good. The changes to event_service.py seem over complicated to me when compared to just decoding the request in the request_reply_handler as necessary. But implementation looks good if we do want this feature.

[Hackerman342]

This should be used in the setter above

[edgarriba]

it's more safer from user perspective to have a method which includes logic to avoid that they directly manipulate the member function (even via setter decorators). The motivation of this feature is same as before, to remove boilerplate code for calling payload_to_protobuf in the callbacks on the user side. In the way it's done is backward compatible but i would advocate to use/update the new function in future version to make it more safe.

[Hackerman342]

But as it is right now, there are two ways to set the request_reply_handler and a user could easily make the mistake of setting:

myEventService.request_reply_handler = my_handler_that _expects_two_args

To me it seems much safer if we change to:

    @request_reply_handler.setter
    def request_reply_handler(self, handler: Callable) -> None:
        """Sets the request/reply handler."""
        # self._request_reply_handler = handler
        self.add_request_reply_handler(handler)

That or we remove the setter altogether. As it is right now there is too much error potential

[Hackerman342]

Since you've already merged I moved it to #165