One other thing that I forgot to mention is that I would be in favor
of adding a new message type for asynchronous calls, even though
it would changing the wire format and could be kind of a pain to roll
out.
I figured the wire format would not be a problem if the version number is
increased, because older servers could simply respond with an error
message. Unfortunately this will not work because the client does not
expect anything to be returned when sending a message type indicating a
one-way request. Also, new message types expecting a response that does
not have the older format cannot be properly responded to by older servers.
I guess it is only possible to maintain backward compatibility. Forward
compatibility would put too much constraints on the possibilities of new
protocols. The only option for older servers receiving unknown, new
message types is to close the connection. This would give the client no
clue as to why the connection is closed, but there is no way for a server
to communicate the information that works in all situations.
A workaround might be a service/message type that returns the version of
the protocol implemented by the server. This could be part of the
protocols, or be implemented as an application service. A client
connecting to a server can check the version and report immediatly if the
server supports the minimum version needed.
--
Kind regards,
Johan Stuyts
