Hilarie,
You mentioned that a new custom OCP transport is the best way
to proceed, but did not follow up on that suggestion. As of now, we
seem to have two existing transports to consider: BEEP and HTTP. Do
you still think a new, custom transport would be better? If yes, can
you elaborate? You can use my specific questions below to start with
(they split the problem into two semi-independent parts: new versus
old transport and reliable versus lossy transport).
It would be great to have more information so that we can
summarize the advantages/disadvantages of all transports and make the
final selection.
Thank you,
Alex.
On Thu, 17 Apr 2003, Alex Rousskov wrote:
On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote:
Personally, I think the best choice is a new transport named OCPTRAN
that can run over TCP for data that needs reliable service and can
also run over UDP or just IP if need be.
If the group is convinced that designing a new transport is a good
idea, one way to proceed is to take BEEP, remove its XML dependency
(unless we choose to use XML for OCP messages) and remove mandatory
responses. Doing just that will allow us to reuse a lot of existing
documentation (and even code). Hilarie, could you please try to
convince us that new transport is needed assuming no UDP support is
required?
Hmm... The above can be rephrased in a more direct way, I guess:
Hilarie, what is wrong with BEEP, assuming no UDP support is required?
Once we know what is wrong, we can see what it would take to fix it.
If the group is further convinced that unreliable transport support is
needed, I would suggest that we add lossy transport support to the
above. Hilarie, could you please try to convince us that unreliable
transport support is required? More specifically, what kind of
application protocols cannot be adapted with OCP/TCP using a
reasonable set of OCP transaction timeouts to accomodate slow callout
servers or bad connectivity to them?
Thank you,
Alex.