>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 at pwg.org
12/17/97 07:59 AM
Please respond to ipp-owner at pwg.org @ internet
To: ipp at pwg.org @ internet, smg1 at 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 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 th=
e
> spec developers I thought I would mention this. Steve
=