[
Lists Home |
Date Index |
Thread Index
]
On Mon, 2002-02-11 at 22:43, Mark Baker wrote:
> > The question I'm raising isn't about exchanging information. It's about
> > the entire notion of a function framework. I'm much more interested in
> > pure messaging than small sets of _functions_.
>
> "pure messaging" most often refers to the transport and/or session
> layers; getting bits from A to B with some desired QoS with message
> correlation, etc.. While the interest at this layer perks up every so
> often (MUX, BEEP), the real work gets done at the layer above this, the
> application layer. This layer *MUST* be based on some set of
> "functions", because that's how application layer agreement is made.
Uh, no. That may be a useful and conventional view of protocol
creation, but it's not at all what I have in mind. All I have in mind
is A -> B messaging, where the only conversation B is required to have
back to A is an ack - and even that's fairly generous.
If you wanted to define that as a function call we could say:
public void send (URL destination, XML message)
Is that just a socket connection? Yes, most likely. Do we need
agreement above that level to get things done? Most likely. Does that
agreement need to be spelled out formally in a contract? No, I don't
think so.
If you _want_ to define functionality above that you CAN, but there is
no MUST. As long as we know that the stream is in XML, we can do
interesting and possibly useful things with it.
Is that architecture sufficient? It depends entirely on who you are.
If you want more, you can build on that. If you're content with that,
you can work directly with those messages. (I plan to do so.)
There's nothing magical here - just work to get on with. I like it that
way. (And some purists might go as far as UDP messaging, but I'll admit
to finding TCP as far down the stack as I care to venture.)
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
