Re: Forms support in clients

Karl Auerbach (karl@cavebear.com)
Wed, 28 Sep 94 10:03:55 PDT


>> "watcher" into a server. Some mechanism, not yet existing, would have
>> to be invented to let the watcher tell my viewer that something new
>> and interesting (as defined by my script) is out there. Then my
>> viewer could have the new document fetched, my coffee brewed, and my
>> slippers handy when I got up in the morning.
>
>How about.... email?

Yes, it can be made to work, but it is certainly a clumsy architecture.

(My approach would be to e-mail a C program which would be compiled
into a Scheme interpreter which would await a subsequent e-mail with
the scheme program... :-)

I geuss when all you have is a hammer (i.e. e-mail transport)
everything looks like a nail (e-mail messages.)

>The thing you have to ask yourself is what happens if 1) you're not logged
>in, 2) you're not running a viewer, 3) your machine is turned off, .... when
>this new document arrives.
>
>Why not just extend your email viewer to handle external references that can
>include URLs in addition to anon-ftp and all that stuff?

E-mail has it problems too. And it is so overloaded with mechanisms
that it is a noisy, high administrative overhead channel, one that
often takes system level privileges to configure. Moreover, there are
a lot of non-un*x boxes out there in which e-mail isn't quite as easy
to manipulate.

>> Using the Shepards model -- suppose I'm researching a-b-hydrolithium
>> as a cure for aging. I'd want to put a script into the servers for a
>> number of of journals to inform me of any document that is added that
>> refers to a-b-hydrolithium or any document that had a citation to Dr.
>> Foo's groundbreaking paper on the use of lithium "A" compounds.
>
>But what's the mechanism for telling you? I think that's what the question
>is to be answered. -- Darren

That's why I'm following this thread (probably much to the bother of
some folk.)

In my own network management related work, we handled this by coming
up with an "association" concept that/protocol that has a lifetime
longer than a single transport (indeed, it is transport agile -- able
to leap to IPX/SPX or dial-up if needed.)

--karl--