IPP Mail Archive: RE: IPP> Get Attributes

RE: IPP> Get Attributes

Carl Kugler (kugler@us.ibm.com)
Wed, 17 Dec 1997 15:54:05 -0500

>The awkwardness of having get-attributes for both
>printer and job objects depends on how you implement
>the server.

Then why not make 2 separate methods and avoid constraining the
implementation? Keep in mind that implementers don't always get to sta=
rt from
a clean slate. One might be reusing legacy code, or extending an exist=
ing
product, or using a platform that makes multi-threading difficult.

-Carl

ipp-owner@pwg.org
12/17/97 07:59 AM
Please respond to ipp-owner@pwg.org @ internet

To: ipp@pwg.org @ internet, smg1@vnet.IBM.COM @ internet
cc:
Subject: RE: IPP> Get Attributes

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@vnet.IBM.COM]
> Sent: Wednesday, December 17, 1997 8:34 AM
> To: ipp@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 th=
e
> spec developers I thought I would mention this. Steve

=