Reinaldo Penno wrote:
I guess there are two approaches here:
1) Making extensions for every single application protocol that might use
OPES.
...Although some people that in realitly we will have maybe 4 (HTTP, RTP,
SMTP, FTP).
Just a reminder - although we've a SHOULD requirement that states that
our solutions should be protocol agnostic (and I think we all agree on
that), our charter is focused on HTTP (and RTP, although we agreed the
main focus being on HTTP).
2) Developing an out of band protocol to signal such preferences. That's why
I said in the past looking at NSIS could be interesting if we feel the list
in 1) is already big/complicated enough or might grow.
There is also the practical uses of either approaches. Certainly,
negotiating with the OPES processor what will/not receive treatment every
single HTTP session could add a lot of overhead. Although HTTP could be used
to negotiate, I guess we should have provisions to say "bypass OPES for all
HTTP sessions, until I say otherwise", or vice-versa.
I'd suggest we go down a similar path as we currently do with the
callout protocol, namely discussing required functionality and general
design issues, first (rather than starting to discuss how and in which
specific form to do it). I.e. what exactly do we need to signal (one
example is the "OPES bypass"), what are the interaction schemes, what
needs to be signaled, etc. Then we can discuss what's the best way to
do this (e.g. "in-band" vs. "out-of-band") etc. [Note: Just to avoid
confustion - this is *not* about the callout protocol, this is about
the application protocl path).
Maybe Abbie and Reinaldo you want to take a first shot, since you seem
to look at this from slightly different perspectives. Of course,
anyone else should feel free to take a first step as well...
-Markus