My understanding is that Michael's statement was that he is not
prepoared to make this kind of change as a last minute change to
his current release. I did not interpret that as "it can never
be done". Doing Ira's new objects instead would not have changed
that I expect.
However, it seems that this discussion isn't over yet.
> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Jay
> Sent: Tuesday, March 21, 2000 5:19 AM
> To: IPP Mailing List
> Cc: McDonald, Ira
> Subject: Re: IPP> New CUPS 1.1 beta and set-job-attributes extension
> [why not use "job-sheets"?]
>>> Would someone be interested in presenting a *short* (and I mean
> SHORT) paper
> on the Pros and Cons of "Collections" vs. "Objects" with respect to IPP?
>> It would appear Michael Sweet has some compelling arguments for
> his position,
> particularly given the product his company has produced. That
> is, when he says
> the current state of IPP makes it difficult (impossible?) to
> implement certain
> key capabilities, doesn't that raise a big flag?
>> If someone has already published a short paper, please forgive
> me, and point
> me to the document in the archives.
>> PS: Keeping my long-held consistent view, "absorbing" anything
> from ISO DPA
> sends more than a modest shiver up my spine.
>>> "McDonald, Ira" wrote:
> > Hi Michael,
> > Thanks. You added a voice to mine (the one out in this
> > wilderness on recent IPP WG Telecons) saying that 'collections'
> > were not really a 'simple' extension.
> > I have grave reservations about ANY future point version of
> > IPP making support for the 'collection' syntax mandatory.
> > Even with the latest 'legacy friendly' encoding proposals
> > from Bob Herriot (thanks Bob), I'm not a fan of 'collections'.
> > In essence, 'collections' are 'poor man's objects'. I still
> > haven't heard the compelling case for why we wouldn't just
> > use REAL objects (for example 'Resource' object, in the ISO DPA
> > 'document resource' sense of fonts, forms, logos, etc.).
> > Cheers,
> > - Ira McDonald, consulting architect at Sharp Labs America
> > High North Inc
> > -----Original Message-----
> > From: Michael Sweet [mailto:mike at easysw.com]
> > Sent: Monday, March 20, 2000 7:33 PM
> > To: Hastings, Tom N
> > Cc: IPP Mailing List
> > Subject: Re: IPP> New CUPS 1.1 beta and set-job-attributes extension
> > [why not use "job-sheets"?]
> > "Hastings, Tom N" wrote:
> > > ...
> > > Wouldn't it be simpler to use these values in CUPS, rather than
> > > introducing two new Job Template attributes?
> > 1. The PPE uses COLLECTIONS for this stuff
> > 2. Collections are still being defined.
> > 3. CUPS currently does not do anything with collections (it will
> > store the raw data, but that is all)
> > 4. Without collections the job-sheets attribute cannot support
> > what CUPS needs to do.
> > Given those things, it is unlikely in the EXTREME that we will
> > change our design this close to a final release.
> > It is *possible* that we can change the names of the attributes
> > to "job-sheets-*", however I am concerned that we might step on
> > future attributes. Possible names:
> > job-sheets-supported
> > job-sheets-start-default
> > job-sheets-end-default
> > job-sheets-start
> > job-sheets-end
> > At least that would be in line with the IPP spec, but that also
> > means we must support "job-sheets" and "job-sheets-default". I'm
> > not sure how we would map that given the ambiguity in the spec...
> > Another possibility might be to overload the "name" value to use
> > "start,end" for the "job-sheets" and "job-sheets-default" attributes,
> > however that might break clients that try to compare them against
> > the "job-sheets-supported" values.
> > In any case, any change we make now CANNOT include support for the
> > PPE spec.
> > --
> > ______________________________________________________________________
> > Michael Sweet, Easy Software Products mike at easysw.com> > Printing Software for UNIX http://www.easysw.com>