Tom Hastings wrote:
>> In discussing the host-to-device requirements, we came up with a requirement
> that the printer be able to feed back information about whether it was
> choked up with data or needed more data for the current job.
>> So we could have events like:
>> Slow down data transfer
> Speed up data transfer
I agree with others comments regarding these events... I think that
is an issue for the underlying transport.
However...
> There is an even more important event for a device to send to a host:
>> Ready for another job
I think that this could/would be a very useful event. As Tom pointed
out, it is another case of something that is more appropriate for the
host->device protocol than it is for a client application (I know that
I am probably starting to sound like a broken record, but I think that
it is important to point out these differences, as there are some who
believe that there are none).
The one point that I would add about a "ready for job" event is that,
unless we make notifications absolutely reliable (very unlikely), an
application could not rely on just this event to know that a printer
was ready to accept another job. In that case, we would also want to
model this piece of information as an attribute (or some sort of state
value) for the printer. That way, if the server application missed the
"ready for job" event, it would still be able to pick up this information
by polling the printer object.
...walker
--
Jim Walker <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX