[printing-discuss] Last Thursday's Call

[M. Drew Streib]

Following are some notes from last Thursday's call. They are somewhat rough,
but I need to get them out.

Basically, we discussed the spooler API more in depth, in terms of requirements
and some basic expected functions. We went into some depth on the driver
requirements as well, but expect to discuss this more on this coming
Thursday. The capabilities API is also likewise scheduled for the next
call.

Norm covered some of this as well in his recent post to printing-spool@,
so this repeats some of that.

***Spooler API / Job API / Queue API

We decided to speak to these three APIs as one group.
Some basic requirements:

* create objects
  - jobs
  - documents inside of jobs
* gather state
  - attributes of queue itself
  - job information
* control queue
  - enable/diaable
* manipulate jobs/queue

Requirements from the application/user level:
 - submit jobs
 - get status
 - cancel jobs

Requirements from a management level:
 - queue setup
 - change state of queue
 - change resources
 - change configuration
 - start/stop processing
 - requeue jobs

We also need enumeration for the gui to be able to manipulate objects.

We also need to be able to at least transport capabilities information via
the spooler API:
 - not interpreting midstream the data itself
 - leave up to components to intrerpret

Security concerns/approaches:
  - should not specify specific security scheme/mechanism
  - will do generic
  - pass tokens as part of stream
  - may or may not include token request, etc

Till - encrypted transmissions?
  - handled by network protocol, could be independent of api

Implementation details:
  - shared library
  - fixed headers

There was some discussion of spooler cascading (having a local and network
spool, or multiple network spools):
  - translations w/different protocol
  - some method to remote number/identify spoolers?

There was also discussion of where to inject policy and per user capabilities
and permissions:
  - handling at a layer below? (security)
  - or above? (handle at application)
  - policy enforcement, display to applications
  - where is this policy stored? do we also ask application to check it?
  - may need to pass rules as well, maybe later

Till brought up backchannel communications, but we know that this may be
dependent upon an as yet undetermined notification API:
  - may need to pass with information on how to reach user with notification
    information
  - needs to include remote notification, or when the submitter is no longer
    at the local machine

*** capabilities api

More capabilities discussion is scheduled for this thursday.

will work from ben's post to the list

  - may need to make more generic
  - will need a way to arbitrarily define information independent of
    api itself, so api doesn't have to change when new information is
    added

*** driver api

This summary is posted now on printing-driver at freestandards.org. More
discussion is scheduled for this thursday.

-drew

-- 
M. Drew Streib <dtype at dtype.org> | http://dtype.org/
FSG <dtype at freestandards.org>    | Linux International <dtype at li.org>
freedb <dtype at freedb.org>        | SourceForge <dtype at sourceforge.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/printing-discuss/attachments/20011113/dd28d306/attachment.pgp