Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
In yesterday's call, I think it was Tom who suggested that a printer
condition affecting the flow of data (such as out of paper) could be
signaled asynchronously on a separate channel, leaving tcp flow
control to manage holding up the data and restarting the flow when
the printer problem was cleared.
I am very hesitant to do this on a completely different channel (and
by the way one that is not actually part of IPP). If we ever do get into
situations where it is desireable or necessary to synchronize between
the client and the server, it becomes very difficult when dealing with
two completely different channels.
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.
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".