>>> <rdebry@us.ibm.com> 02/27/97 12:20pm >>>
> o The user might turn notification off
> o The user might not "see" the notification, i.e. only looks at his email
> once a day.
> o The client will not see the notification, since it goes directly to the
> user.
> o The Printer has no choice but to wait until the condition is fixed, then
> continue to receive data
> o The client has no choice but to wait until the Printer begins receiving
> data again. It could detect that no data is flowing and warn the user,
> but it does not know why data is not flowing.
Yes, but sometimes this is what the end user wants is to turn this stuff
off. In the Novell environment, we find that people turn off notification
very frequently.
> This may be a dumb analogy, but consider the situation where I call my
> friend on the phone. As we talk, he smells smoke and discovers that
> his
> house is on fire. He says "wait a minute", and without saying anything
> more
> he goes away, leaving me on the phone waiting for him to say "go
> ahead".
> He then writes a letter (a separate channel) telling me his house is on
> fire,
> then proceeds to try to put it out. Seems pretty silly when compared to
> just
> saying "wait a minute, my house is on fire".
Not a dumb analogy, just one that is not applicable. A voice telephone
connection is a free flowing, abstract, not specific, bi-directional channel
where there is no clear client or server. You do not have to say
something to get something back. What if it was a request response
channel like HTTP and your friend wanted to say his house was on fire
but you had nothing to tell him -- The line is silent, he can't say anything
because you are quiet and he can only respond to what you say. On
the real phone line, he can say "Hey, be quiet I have something important
to say" while you are talking. We do not have such a connection and it
would be a major change in requirement to have such (set up twp TCP
connections).
Scott