Hi.
I hope you have a good meeting today. Wish to be there too.
Here are some comments on the OPES callout protocol requirements:
3.1.3 - While it is good to have the message context taken as binary
data, the protocol has to deal with quoting and special characters.
Passing the context as part of the URL may require some encoding for the
context. Sending the context as additional header fields also runs in
the quoting problem (a reason why ICAP/0.9 didn't really work and
ICAP/0.95 and ICAP/1.0 are transfering the HTTP headers as encapsulated
data in the message body).
3.1.6 - This may not really belong to the protocol but is an
implementation advise. If given it should also remark the oposite
direction: Not only the intermediary should send segments of the message
as soon as possible to the callout server but the callout server should
try hard to process single segments and to send back segments of the
response as soon as possible to reduce latency time for protocols need
short latency like HTTP.
3.2.4 - If the callout server is allowed to interrupt the transmission
at any time, synchronization of the next callout request on that
connection gets quite complicated and persistency of the channel is
endangered.
I rather propose to define methods for multiple decision points and thus
extending the fixed preview feature.
Example: A callout service likes to work with the <HEAD> section of a
HTML file. There is no perfect preview size for this job. But the
service could negotiate a small first preview length of just a few bytes
to check whether the file could be a HTML file at all. If yes it could
reply on the first preview to continue and to get another chunk (of
maybe 1 KB) of data with another decision point such as a second
preview. It can continue this way until the end of the <HEAD> section is
reached.
Martin Stecher
mailto:martin(_dot_)stecher(_at_)webwasher(_dot_)com