I have noticed the same problem during my implementation.
With printer operations except Get-Attributes, the presence of a job-id
is an error. With job operations whose target is a printer-uri except
Get-Attributes, the absence of a job-id is an error. Because
Get-Attributes is both a job and printer operation, neither the
presence nor absence of job-id is an error. Rather it determines
whether the operation is a printer or job operation.
I am leaning towards Steve's idea to have two operations Get-Job-Attributes
and Get-Printer-Attributes.
> From rturner at sharplabs.com Wed Dec 17 11:53:33 1997
>>> The awkwardness of having get-attributes for both
> printer and job objects depends on how you implement
> the server. If you always have one server handling
> all requests, then you have to check the URL
> on the get-attributes request to determine if the URL
> points to a job or printer object. If however, the
> server is multithreaded, and spawns multiple threads
> (one per job), then the job-handler threads each have
> their own URL and any get-attributes request sent
> to a job-URL goes to the job object "thread" and no
> check has to be done.
>> Randy
>>> > -----Original Message-----
> > From: steve gebert Dept:ecg SN:579517 Div:ISM Ext
> > [SMTP:smg1 at vnet.IBM.COM]
> > Sent: Wednesday, December 17, 1997 8:34 AM
> > To: ipp at pwg.org> > Subject: IPP> Get Attributes
> >
> > I know this has probably been mentioned before, but as I am getting
> > more into implementation I am finding the use of Get-Attributes on
> > both the Printer and Job object to be ackward with regard to
> > implementation. It is the only case of a method being dependent
> > on the object and introduces some special case processing that could
> > be avoided by having 2 distinct methods. It seems that with regard
> > to consistency it would be better to have 2 methods that are
> > similar and consistent with the other methods (Get-Printer-Attributes
> > and
> > Get-Job-Attributes). In addition, I think, at least based on my
> > limited
> > experience, that perhaps the implementations could be a little
> > simpler.
> >
> > Since part of the reason for prototyping is to provide feedback to the
> > spec developers I thought I would mention this. Steve
>