1. I believe that the protocol requirements stipulate the use of
independent "channels", and those were put in exactly for the the case
you are discussing for preview. If channels don't solve the problem,
we need to know why.
2. For the SMTP case, let's suppose that the site policy requires virus
scanning, but some subscribers to the OPES box want potential viruses
removed, and some simply want them flagged. Assume a message has been
sent to several recipients of a domain with an OPES virus scanning
service, and its body is denoted as "A" (identified by its hash, I
suppose). If it's the OPES processor that holds the user preferences,
then it can handle the process of sending A to a callout server for
virus scanning and asking for both removal and flagging, possibly in
one request, but at worst in two. Ah, I see, you'd like to eliminate
the two requests, and have a request type that asks for multiple
services and multiple replies. This is different from asking for
multiple services and one reply. A notation for this might be something
like:
Request(data=D; service=A AND service=B)
Reply(data=A(B(D)))
Request(data=D; service=A; service=B)
Reply(data=A(D); data=B(D))
Have I captured the requirement correctly?
3. I know the arguments for simple formats, but please give something
specific about your objection to BEEP. My objection to XML encoding
is that it requires many instructions to parse it into tag pairs and
parameters, to create a parse tree, and to traverse the tree. When
comparing this to direct indexing, or even scans for end-of-header,
end-of-line, XML is very slow. But, experience has shown that there
are distinct limits to what can be accomplished with fixed parameters
positions and bit encodings, and even TCP has had a great deal of
trouble staying within its header limitations. Up at the application layer,
I think some compromise will be necessary. I'd thought BEEP was actually
a good point to begin looking for that compromise point. What is so
awful about it?
Hilarie