I disagree with this. The processor provides a simple interface for
selecting a function to call, deserializing its arguments, and
serializing its return value. It implements a part of the protocol,
so replacing can potentially break wire-compatibility. I don't think
that it is a component that should be replaced lightly.
It provides only one way of processing a request, and most of the
protocol-related logic is encapsulated in the parameters and the result,
and their wrappers. The rest of the logic is duplicated in each processor
and not very complicated. Reimplementing this logic once for each of the
few client and server implementations, and keeping the implementations in
sync is not a big burden in my opinion. The added benefit of moving the
logic to the client and server implementations is that bug fixes do not
require regeneration of existing code.
I would like for clients and servers to be able to handle requests anyway
they like. Handling a request consists of the following parts and how and
when these parts are executed should be flexible:
- reading the request message header
- asking the function to read its parameters from the input protocol
- executing the function
- writing the response message header (for success and failure)
- asking the function result to write itself to the output protocol
I meant that this could be added in addition to the current synchronous
interface. The problem with having a "standard" interface for
asynchronous
calls is that every language has a different way of expressing callbacks
and asynchronous I/O. This doesn't mean that we shouldn't try to present
a reasonably uniform API, but it does mean that it is a fairly ambitious
cross-language project.
Why does the way in which you handle asynchronous calls in one language
have to resemble how you implement it in other languages? I think we
should design the asynchronous call API for each language separately so it
feels natural to developers using that language. Also some languages might
provide native constructs for asynchronous calls not available in or
widely different from other languages.
These are both possibilities (and I think TProtocol already supports
input
and output transports). The downside is that it eliminates the nice
property that you have just one object that manages all of your
communication
with the other side.
The current code already supports separate protocol objects for input and
output, you never use functions for reading and writing at the same time,
and I see two responsibilities: input and output. From a design point of
view I would use two types. Anyway, it is not a big issue. Both ways will
work fine.
--
Kind regards,
Johan Stuyts
