Hi Jay,
I don't think there is a white paper on 'collection' versus
'object' pros and cons.
I didn't mean to imply that the use for 'object' was to
'absorb' something from ISO DPA. There has been some
discussion on recent IPP Telecons about requirements to
enhance IPP to comprehend fonts/forms/logos. And some
concensus that it would be best done with a new 'Resource'
container object.
I do agree with Michael that exploring the development of
new syntaxes (base datatypes) is often preferable for
simplicity and robustness of implementation to the use of
the 'collection' (bag of bits) syntax. I also think that
when a new syntax won't do, real objects (like we are adding
with the Subscription object) are also preferable to the
use of 'collection'.
I am dubious about the arguments that 'collection' can't
simply have the WHOLE length of the 'collection' computed
and inserted in the attribute. Device or clients that need the
functionality that (purportedly) requires 'collection' are
certainly capable of building the whole 'collection' in
memory or on disk before sending it.
And a whole lot of protocols that use ASN.1 encoding over
the wire (LDAP and SNMP among them) decided that only
'definite' encoding rules were legal - that is, they banned
the ASN.1 use of 'here are some bits - watch for some flag
octets to find the end of these bits' as not worth the
bother.
Of course, IPP gets most of its attributes and most of the
semantics of its operations from ISO DPA. So it's a little
late to shiver...
Cheers,
- Ira McDonald
-----Original Message-----
From: Jay Martin [mailto:jkm at underscore.com]
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.
Thanks,
...jay
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