Re: Forms support in clients

Nathaniel Borenstein (
Wed, 28 Sep 1994 12:47:06 -0400 (EDT)

Excerpts from www-talk: 28-Sep-94 Re: Forms support in clients Karl
Auerbach@cavebear.c (1449)

> 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 "" 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