On Thu, 17 Apr 2003, Marshall Rose wrote:
all i can say is that your perception about xml appears to be at
variance with my impression of a lot of other people's perceptions.
Good! Since my view is rather pessimistic, I would rather be proven
wrong. :)
If somebody takes a shortcut in supporting the XML part of BEEP, it
would be trivial to prove that their implementation is not OCP
compliant by sending an "interesting" (difficult to parse but valid)
XML element as a part of a channel management routine.
the xml subset used by beep makes that rather difficult.
Thus, we would either have to close our eyes on this problem and
test with simple XML elements only, or we would have to
acknowledge that many (most?) OCP implementations are not really
compliant. Not a nice choice.
i think it's a false choice. anyone who can wade through and understand
the opes specifications, will have no difficulty dealing with xml. let's
keep our perspective here.
It is not a question of misinterpreting the specs. The shortcut I am
talking about is a deliberate action. For example: "For simplicity, we
will assume that CDATA will never be sent to our server as a part of
BEEP channel management; let's not handle CDATA!". And then some OPES
processor decides to send its copyright statement in CDATA...
What do you think about documenting an even simpler XML subset and
recommending (requiring?!) its use within OCP/BEEP? Would that
help at all? Did you consider that option when designing BEEP?
no, because then you move out of the realm of widely-deployed tools.
that's why canonical xml is a bad thing: it requires the use of
special-purpose libraries.
Right. Since I assume that most decent implementations will have to
use special-purpose libraries anyway, it is not a problem for me. So
it all boils down to whether appropriate XML libraries are available
for the majority of real-world implementations we care about. I am
skeptical; you say the majority think that they are indeed available.
the reason why MSG's get a response is because until you see the
response, you never know if the the MSG actually got to the other side
and got worked on. ultimately, it's the application, and not the
transport, that's responsible for things like that (cf., Clark, etc.).
Yes, that is why the always-respond restriction in BEEP seems out of
place. Some applications (like OCP) do not care whether certain OCP
messages are already being worked on (a pipeline model).
ok, do you care that they actually got there or not?
I know they would get there because I use lossless transport (I would
be notified if something goes wrong). I do not care about the timing
though (because it is a pipeline/stream). I am only interested in the
adapted data sent back; that adapted data may come at any time, even
before [some of] my original data reaches the other end(!)...
if you don't need an acknowledgement for each MSG, you can do what
reliable syslog does, wherein the server sends a MSG when the
channel opens, and the client sends back zero or more ANS in
response.
Yes, of course. The problem is that the server does not "want" to send
any MSG until it gets data from the processor. I understand how to
hack what I need using BEEP mechanisms, but they seem to go against
the logic/semantics of what is going on. What I need is:
Processor(client): start, data-have, data-have, data-have, ... end
Server: start, data-have, data-have, ... end
without much of a relationship between the two lines/flows. What I
would have to do with BEEP is:
Processor(client): server-can-start(MSG)
Server: processor-can-start(MSG)
Processor(client): start(ANS), data-have(ANS), data-have(ANS)...
Server: start(ANS), data-have(ANS), data-have(ANS)...
or some variation of the above.
The first two messages are not needed from OCP point of view, but are
required by BEEP because it supports multiple responses for one
request but not multiple requests with one response (essentially).
We may be able to hide server-can-start and processor-can-start MSGs
behind some other OCP messages that must be sent anyway, but that may
increase the confusion.
Is there a better way?
Thank you,
Alex.