Good. Now you're using terms that make sense to me. It's a question of
APIs and programming models, in a way [unless and until we really
start talking about sending different bits over the wire, like the
MDMA folks...].
>One advantage of the SEND/RECEIVE model is that the application can not
>assume that it is going to immediately get a reply back. This forces
>the developer to structure the application in such a way as to allow the
>user to continue working while the RECEIVE activity is going on. Yes, this
>is more complicated than doing a write and sitting there on a read until
>all is done, but so was event-based GUI programming vs. prompt-based
>command-line interfaces. Programmers were dragged kicking and screaming
>into event-based programming, but everything seems to be fine now (:-)
Hah! I think there's an awful lot of kicking and screaming still going
on. I've met a few people that are good at developing apps based on
the OSF/Motif API, but none who like it! The NeXTstep folks seem pretty
happy though, I guess. But NeXTstep has threads, doesn't it?
>What we really need is an event-based networking architecture that
>takes care of all the underlying grunt work and just notifies the
>program when something is done.
It's called threads. Developing distributed applications without
threads is enough to drive anybody batty. I spent a year writing a DCE
client with a Motif UI. I could use threads to do DCE stuff, but only
one thread could put it's fingers in the Xt/Motif data
structures. It's a royal pain in the @#$.
That's why I'm so keen on Modula-3: nice gui libraries, threads and GC
in the runtime, yet still allows systems programming and direct
interfacing to C libraries.
Dan
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<connolly@hal.com> http://www.hal.com/%7Econnolly/index.html