On Wed, 12 Mar 2003, Abbie Barbir wrote:
The discussions give me the feeling that we are trying to design a
(very flexible) system that is looking for a place in the field.
I do not think the situation is that bad. We are trying to design a
flexible system with a few _known_ places in the field. We have a use
cases draft. We have every existing ICAP system as a "place". We have
a few other very specific examples discussed on the mailing list.
There were some very vague discussions/examples as well. Perhaps they
create an impression that we are designing a general-purpose no-place
system. The primary reason vague examples and requirements should be
discussed is to make them specific; at that point they can be included
in or excluded from OPES scope.
I could see the benefits to have various bindings for the callout
protocol. It gives felexibility. But at what expense? I really have
problems developing an architecture/protocols that can go all over
the field.
I agree that it is easier to design with one binding in mind. However,
I am in favor of a slightly different "lazy binding" approach: design
without specific bindings until specific bindings become necessary to
proceed. Most of the issues that have been discussed and solved so far
are binding-independent. I would suggest to postpone any binding
decision until it actually becomes necessary.
There is some overhead in this approach, but I think it is small. On the
other hand, it is much more expensive (and often nearly impossible) to
add bindings to a single-binding protocol.
The architecture document states that the example protocol is HTTP.
I know that we should be open minded in the design of the callout
protocol.
I try to keep the following list of protocols in mind:
Application protocols it would be nice to support:
- HTTP
- SMTP
- RTSP
- instant messaging protocols
Transport protocols we may want to support:
- raw TCP
- BEEP over TCP
- HTTP over TCP
- SOAP over the above
I still need to learn more about SCTP, but it should be added to the
above transport list.
With application protocols, we want to support as many as possible.
With transport protocols, we want to have just the necessary binding(s).
But, again, I prefer to make decisions when they become necessary.
However, I would like to start with HTTP and then come up with a
callout protocol that can work with it. After that, I would like to
see how we address all of the IAB issues regarding OPES. We can then
move the excerise to RTP (SRTP etc..), and use that knowledge to
ensure that we have a flexible protocol.
I disagree with the ordering, but I think we can still work together
while preserving the differences in approaches: you can assume HTTP in
all future discussions (while keeping the end goal in mind), and I
will assume a group of protocols. There should be no significant
design conflicts until we actually have to make the decision of what
application protocols to support.
I think adding support for very different application protocols on top
of a nearly finished OPES design will lead to kludges and inferior
results.
At this point, the issues of notification/tracing have not been
brought up (yet?).
I am finishing up the next version of the predraft protocol. The
biggest new additions are cleaner message hierarchy and connection
management functions, based on the discussions on this list. I plan to
address tracing and user preferences next, unless somebody beats me to
it.
Alex.