On Tue, 15 Apr 2003, The Purple Streak, Hilarie Orman wrote:
First, I know I asked about whether or not a transaction was
supposed to be kept on a single connection, but I cannot find my
question or the answer in any archive, so, annoyingly to everyone,
including myself, I need to ask again.
IMO, the requirements draft semi-implies that a single transaction
cannot cross connection boundaries. OCP Core follows the same
principle though we need to explicitly document this fact (added to
the todo list).
OCP Core will allow certain OCP messages with xid to be sent on
several connections to support fast-abort and similar optimizations
(you may recall a thread about it on this list). The latter feature is
the "fast track" item on the todo list.
If I am reading things correctly, the requirements allow several
"connections" over one transport connection, but OCP forbids it.
Is there disagreement? If not, which notion is correct?
OCP Core does not forbid several OCP connection over one transport
connection (bugs notwithstanding). OCP Core says, in part
("Connections" section, blob 87):
If BEEP over TCP is used, than a BEEP channel will correspond
to a callout connection, allowing callout connection
multiplexing over a single TCP connection.
What made you think that "OCP forbids it"?
The requirements mention "keep-alives" and "heartbeats". Was there
any intent to require heartbeat support? OCP does not use them,
which is fine with me.
OCP Core supports heartbeats via <i-am-here> and <are-you-there>
messages. Those are actually very useful because OCP Core relies on
timeouts to resolve possible problems with overloaded or
malfunctioning agents and timeouts without heartbeats do not work well
for "slow" adaptations.
Reviewing the messages on this list, I find myself deeply uncertain
about what would be in "OCP/HTTP bindings". Would it be an encoding
of the OCP protocol elements (transaction start, transaction id,
etc.) as HTTP-style headers?
You may be confusing/mixing OCP transport binding and
application-specific drafts. We have not decided on OCP transport
binding. In theory, it can be HTTP like in ICAP. If that is the case,
then either OCP Core (if there is only one transport binding) or HTTP
Transport Binding for OCP (if there are multiple transport bindings)
drafts will indeed document how to convert OCP protocol elements to
HTTP elements.
On the other hand, if OCP transport binding is, say, BEEP, then there
is no need to convert OCP protocol elements to HTTP elements. There is
a need to document how OCP protocol elements are encoded within BEEP
channels, of course.
In order to allow someone to write an Apache module for OCP and make
use of the HTTP header parsing libraries, for example? And bring in
all the baggage about chunking? If so, we need to state this
somewhere, and say why we are doing this, rather than defining
protocol-independent bindings. The "application agnostic" stuff
seems to lead one to expect protocol-independent metadata. This is
why I am deeply confused. Further, if there is a truly application
independent encoding, say, for mime parts, then why not just use
this as the single encoding? At one time it was very important to
use HTTP bindings for this code reuse purpose, but I'm not sure that
is still the case. Can we document a decision on this point?
I may have mentioned that before, but I think we need to decide on OCP
transport binding(s?) first. Once we know the transport, we would be
able to decide how to document OCP encodings. Or, at least, the two
decisions (transport and encoding) should be done simultaneously
because some high-level transports (e.g., HTTP) have strong influence
on encodings.
Answering this question will make OCP much more clear for people who
need message syntax before they can understand a protocol (the
majority of practitioners, I guess).
OCP's negotiation section hints at a rich set of operations; do we
need more than the usual "here's my menu" and "here's my selection
from your menu" ?
We are waiting for Reinaldo Penno to give us an answer. You can ignore
negotiation messages until then.
I confess to not understanding the big diagram in OCP; it may be an
elegant way to convey information, if I only understood it.
It simply shows incapsulation of protocol elements (boxes within
boxes). As I said in release notes, I am not particularly happy about
it either. Better rendering ideas or examples are more than welcome!
Where are the "data have" messages? Are those "OCP messages" in the
last box?
Yes, data-have message is an OCP message.
What are "connection C" and "connection G" ?
Two [partially concurrent] OCP connections.
I cannot keep myself from stumbling over "application message" time
and again. And again. The stuff between the OPES processor and
callout server that might be encapsulated data coming from or going
to the proxied transaction ... can that have an unambiguous name,
like "zinc", if there's nothing better?
Except for section 1.1, there should be no mentioning of "proxied"
anything. The fact that OPES processor is a proxy is out of OCP scope,
and section 1.1 attempts to document that. "Application message" is
whatever OPES processor and callout server what it to be, essentially.
I would not like "zinc", but would very welcome better alternatives to
describe an undefined (content, metadata) pair.
HTH,
Alex.