Bob did a good job at introducing and summarizing the issues associated with
the "open minded" idea of having both Job IDs and Job URIs. I am really
trying to have an open mind and think new thoughts, but my gut reaction and
continued perception (even after reading Bob's message) is that it is too
cumbersome, and not very elegant. It does not really solve the problems
unless we force ALL Printer implementation to support the passing in and
then passing back out of this helper attribute. That seems ok, but when
implementations must support operations either being addressed to a Printer
(P), or a Job (J), or a Printer plus ID (P,s), and then respond in Get-Jobs
etc with both (J) and (P,s), that sounds very un-ok.
Let's either fish or cut bait.
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************
>>> Robert Herriot <Robert.Herriot at Eng.Sun.COM> 09/05 5:59 PM >>>
It was suggested at the last teleconference that we should have both
Job-URIs and Job-Ids. This email looks at the pros and cons of that idea.
I want to make it clear at the outset of this email, that I am not taking
a position on whether we should have both. Rather I want to explore what
the ramifications are if we have both.
The following are what I think the characteristics of such a solution are.
If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST
support both; otherwise, we are in worse shape than with just one of
them from all servers. Client MUST be free to use whichever they want.
For Print-Job, it doesn't matter whether a client specifies whether it
wants a Job-URI or Job-ID, or whether the server returns both. In both
cases, the server has to deal with both and the client has to be aware
of the choice. So for this discussion, let's assume that the server
would return both.
For Get-Attributes and Cancel-Job, a server must implement these
operations for both Job-URIs and Job-Ids. The target may be a Job-URI
or the target may be a Printer-URI with a Job-Id attribute.
Both Job-URI and Job-Id attributes are mandatory. Thus a client can
query for either via Get-Jobs or Get-Attributes.
The following discusses how this solution works with various gateways.
This solution works well in Win32 because it would use the Job-Id only.
It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways.
The IPP-to-LPD gateways work well because the Job-Id and Job-URL
are both easy to support. So, acting as an IPP server, the gateway can
easily support both together.
The LPD-to-IPP gateway is easy to support with Job-Ids, so such a
gateway, as a client of a IPP server, would use only the Job-Id and
would ignore the Job-URL.
So from a legacy point of view, the solution with both Job-URIs and Job-Ids
is as good as the Job-Id solution only.
But now we need to examine what this change means for server
implementations.
With this change servers would have a bit more work to do because they
would have to offer two ways to do the same thing. Moreover, it is
mandatory that if they support a particular operation, they must
support both Job-URIs and Job-Id. That may be a burden that some
implementors won't like -- more code for some abstract future payback.
I expect that for most IPP servers its Job-URIs will always consists of
its Printer-URI and a Job-Id so the server can easily convert between
Job-URIs and Job-Ids with no architectural additions.
But for servers that want the Job-URI to reference some remote host,
the solution is more complicated because operations, such as
Get-Attributes and Cancel-Job will go to the remote host when the
client uses the Job-URI and these same operations will go to the
Printer when the client uses the Printer-URI and Job-Id. Such servers
will have to deal with forwarding issues and the fact that a Job-URI
that references a remote host does not guarantee that all traffic goes
there because client that use the Job-Id will still come to the original
printer.
As I said at the beginning of this email, I take no position on this
proposal. Rather I offer it as the beginning of a discussion.
I would like others to comment on whether this proposal solves the
problem, or adds too much complexity to servers for the payback.
Bob Herriot