I'm still catching up on this job-URI vs. job-id debate, so I haven't
formed a final opinion. I'm certainly want to be able to put IPP
under existing Print APIs that have the concept of a 32-bit job-id,
because there are so many of them like that.
On the other hand, if IPP did have a job-URI instead of a job-id,
gateways and clients would have to map from the job-URI to a 32-bit
integer for use in the existing Print API. You convinced me (and most
others) at the Redmond meeting that the problem of keeping the map was
knowing when to remove the entry. Suppose such an implementation used
IPP notification to be told by the IPP server when the job had completed?
Then you could remove the map entry from the table. Would that work?
Actually, we would probably have to add another IPP notification-event:
'job-removed' to cover the state transition from 'completed', 'aborted',
or 'canceled' to not being kept in the system at all. We probably should
add that event anyway.
Comments?
Tom
P.S. Hope you can join us for the telecon, this Wed, 9/10, 1-3pm PDT,
since this will be a hot topic for that call.
At 15:35 09/09/97 PDT, Paul Moore wrote:
>The new job MIB defines a 32-bit job identifier that persists as a way
>of identifying a job.
>
>The Win32 API does the same - used on the vast majority of the world's
>desktops.
>
>Bob H says that UNIX uses a 32 bit job ID in the same way.
>
>It's not like I am suggesting that we use something obscure,
>non-published or only used by 1% of the world. I am suggesting that we
>may want to leverage some of the exisiting software in the world.