IPP Mail Archive: RE: IPP> New CUPS 1.1 beta and set-job-att

IPP Mail Archive: RE: IPP> New CUPS 1.1 beta and set-job-att

RE: IPP> New CUPS 1.1 beta and set-job-attributes extension [why not use "job-sheets"?]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Mar 22 2000 - 06:23:19 EST

  • Next message: Michael Sweet: "Re: IPP> FW: Thoughts on the new Move-Job operation"


    Here is a short explanation of collection vs. objects:

    We've identified at least 4 uses of collections for which objects won't
    1. "job-notify" (1setOf collection) in job creation so you can create more
    than one subscription in Job Creation operations.

    2. "printer-xri-supported" (1setOf collection) for setting the three
    parallel printer-uri-supported (1setOf uri, uri-authentication-supported
    (1setOf type2 keyword), and uri-security-supported (1setOf type2 keyword) in
    one Set-Printer-Attributes.

    3. "document-exceptions" (1setOf collection) - to supply per-document
    exceptions to the job level in Job Creation operations.

    4. "page-exceptions" (1setOf collection) - to supply per-page-range
    exceptions to the job and/or document level in Job Creation operations.

    However, the other usages of collections in Job Creation operations could be
    done as objects instead (some say better):

    a. "media-col" (collection)
    b. "job-sheet-col" (collection)
    c. "cover-front" (collection)
    d. "cover-back" (collection)
    e. "job-error-sheet" (collection)
    f. "job-accounting-sheet" (collection)
    g. "separator-sheet" (collection)
    h. font, forms, images, ICC profiles, etc....

    The idea for doing them with objects is to define a Resource container
    object that uses sub-typing to get "media", "job-sheet", "cover-front",
    "cover-back", etc.

    Then define the following operations that work on all sub-types:

       Create-Resource - the creator supplies the unique user friendly name

    Some objects are just a set of attributes (media, job-sheets), and other
    have PDL data too (font, form).

    Each resource object has a unique name within its sub-type. Then in job
    creation requests, the client just supplies that unique name in order to
    specify the object by reference. If the client doesn't know what object
    name to supply in the Job Creation, the client can query the objects (with a
    filter) to let the user find an appropriate object. Then the client
    supplies that unique name in the Job Creation in order to use that media,
    job-sheet, cover, font, etc.


    -----Original Message-----
    From: Jay Martin [mailto:jkm@underscore.com]
    Sent: Tuesday, March 21, 2000 05:19
    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
    particularly given the product his company has produced. That is, when he
    the current state of IPP makes it difficult (impossible?) to implement
    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@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@easysw.com
    > Printing Software for UNIX http://www.easysw.com

    This archive was generated by hypermail 2b29 : Wed Mar 22 2000 - 06:29:53 EST