> Who say's I'm running mosaic or anything like it? Perhaps I have a tool
> on my end that knows how to generate these scripts for the server
> and anxiously awaits a reply?
"Anxiously awaits a reply"? So you're talking about deploying an
infrastructure in which there are permanently-available services to
receive these replies? That's a lot of infrastructure. I don't see any
reason not to just piggyback it on email.
> Yes, it would be nice if the internet had an asynchronous delivery
> protocol. E-mail is being used to approximate it, but it is a noisy
> channel with high administrative overhead.
Why? This doesn't make any sense to me at all. You can set up, for
example, an email alias "karl-incoming-stuff@yourhost.com" that takes
all these server alerts and does something with them locally, if you
don't want to actually see them as email. It can put it into a Web
database that only you can read, if that's your preference. Or it can
consolidate them and then send you a daily digest of your daemon
reports. Whatever you want. Email is ONLY the delivery mechanism. As
such, I think that it gives you reliable asynchronous delivery without
in any way forcing you to use any particular structure for the end-user
interface. What can't you do with email?
> I did an asynchronous text file transfer protocol (way back in the
> very early 1980's -- before sendmail) and it served this purpose.
> IBM's SNADS also serves this purpose. They could carry e-mail quite
> nicely along with other kinds of traffic -- forms, print, etc. It's
> somewhat of an inversion of the concept to try to layer general text
> files over e-mail.
I don't see why, actually. Plenty of people are building this kind of
mail-enabled applications. They can be totally automated, they just
take advantage of email as the only globally reliable infrastructure for
asynchronous delivery. -- Nathaniel