3.
I like to minimize the message overhead (see my performance
considerations in point 5). Together with what I said above
in the first
section, I think that a message header and footer (if a footer is
necessary at all) should be as short as possible. Usually, protocols
write a protocol version into each request and response - but why?
IMO, because it reduces the state to be held by the endpoints of the
connection.
I guess that some parameters that are exchanged during connection establishment
need to be kept anyway; I think that another version field in the state info
will not hurt at all.
On the other hand you are certainly right that the version number overhead is
not a big issue anyway. I just wanted to give an example. There is usually much
more information which is repeated with every request on the same connection.
Isn't
it enough to do this once when a callout connection is
established.? All
the messages within a persistent connection will be of the
same version.
When we try to keep this in mind, every message could be
designed to be
a minimum around the payload.
Messages should also follow a same general syntax to make parsing as
simple and fast as possible and to allow to skip easily
message types
that are optional.
Agreed. IMO this has a greater impact on performance than a few bytes
for version identification.
Correct. But let me again argue why also the little additions can hurt:
If the OPES client needs to wrap parts of the application message in a
structure with parts in the beginning and at the end, this usually means to
copy the message data on application layer again to setup the structure. While
the OPES client will need to forward huge amount of data to the callout
service, reducing the number of message data copies should be helpful.
The thing to remember is that any general purpose protocol will be
slower than a specially tuned protocol. We're building a
general purpose
tool here - so reliability, ease of implementation and
interoperability
are (IMO) greater priorities.
Yes, they are but this does not mean that the protocol has to be slow. If we
also look at these things, I guess that we can have only a little distance to
specially tuned protocols.
If we fail here the OPES protocol could stay a nice academic experience without
relevance to the industry.
Martin