Below are my thoughts on all of the Job URI/Job ID discussions recently.
Even though I have just been a lurker lately, I hope my possition for
support for Job URIs is well known. I endorse 100% of what Randy has
offered.
My ideas:
1) Gateways issues are not the real issue. I agree with Randy's comments
about the IPP model not being constrained by gateway implementation issues
(agreeing with see Randy's comments below). Gateways, by definition, do
impedence matching between two different systems (models). Gateways are
necessary but not front runner cases.
2) The real issue is support for existing client access (API). One of the
most critical features of IPP is that all existing (unmodified applications
and print drivers) can be used with an IPP print provider. We call this
"application printing" (print from any application once the printer has been
"installed" to the desktop). In the Windows enviroments this means writing
an IPP print provider under the EXISTING printing interfaces. In other
environments it means basically the same thing (writing a modular piece that
can slip in under EXISTING interfaces). So the real question is "Can
exiting client printing models and APIs be supported by the new IPP model?"
and remember that I mean all client printing models, not just "one
particular vendor". Again, after all the discussion I am convinced the
answer is YES. The reasons often associated with a NO answer is only that it
would be MORE DIFFICULT, not impossible. I have never seen a "it can not
be done" argument? Did I miss it? This is software, we can do anything!
However, we do need to be pragmatic. What is the exact perfomance vs future
potential tradeoffs? Too bad that is far too unknown right now.
3) In other Internet (non IPP specific circles) there is much theoretical
debate over the difference between URNs (location transparent names) and
URIs (often location dependent IDs). If often wonder if the same principles
in those arguments do not apply to this Job URI vs Job ID discussion (just
up one more layer of abstraction).
Scott Isaacson
>>> Randy Turner <rturner at sharplabs.com> 09/08 2:47 PM >>>
> Overall, I don't consider this particular gateway problem to be
> worthy of altering the original model. The real value in getting
> IPP to users is not enabling LPR clients, its enabling IPP clients
> being able to locate IPP printers via the WEB and subsequently
> printing to them. I think we're spending too much time trying to
> save gateway writers a few lines of code.