From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri,  7 Sep 2007 01:56:30 +0200
From: Enrico Weigelt <weigelt@metux.de>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Message-ID: <20070906235628.GC26188@nibiru.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Subject: [9fans] Ideas for an printer filesystem
Topicbox-Message-UUID: ba2a3a1a-ead2-11e9-9d60-3106f5b1d025


Hi folks,

some toughs about putting network transparent printer handling
to an synthetic filesystem.

I don't want to differenciate between printers and queues,
like most other printing management systems do. Instead I'll
introduce the concept of virtual printers, which may be
connected to one or more existing printers and define their
own options (ie. some virtual workgroup printer distriutes
load between several devices and adds an banner for each user).
Clients only see "their" printer, no matter if its virtual
or physical.


View to the printer repository:

* /printers/
    /drivers/<...>/       lists all available drivers
    /ports/<...>/         lists all available ports
    /all-printers/<...>/  lists all printers (including clones)

View to an single printer:

* /printer
    /config/<opt>          config options
    /jobs.id/<job-id>      contains the jobs, per ID (unique key)
    /jobs.order/<order-nr> the same jobs, but by order nr
    /status                the printer's status and allows to set it.
    /logfile               the printer's logfile
    /clone                 interface for cloing the printer
    /next-id               spits out an new (random) job-id

View to an single job:

* /myjob
    /id                unique key
    /priority
    /owner
    /logfile           the job's logfile
    /status            job's status, writable to alter status
      values: new, processing, printing, done, kill
    /size.total
    /size.done
    /pages.total
    /pages.done
    /colorspace        (ie. rgb,cmyk,pantone,mono,greyscale)
    /papersize
    /orientation
    /options/<opt>     extended options (ie. for folding, etc)
    /content.ps        whole content as postscript

Processes:

* Cloning a printer (to have multiple instances w/ separate options):
  choose some name and write it to ./clone

* Remove an virtual printer:
  write "disconnect" to its status, and the printer will disappear
  once it has nothing more to do

* Creating a new job:
  + fetch a new job-id
  + mkdir a new job queue entry (with fetched key)
  + all necessary structures will appear automatically
  + upload the postscript data to ./content.ps
  + do appropriate changes (ie. papersize, orientation, colorspace, ...)
  + write "new" to ./status

* Abort an job
  + look for the job's dir and write "abort" to ./status
  + the job will disappear once abort is completed

...



What do you think about this ?


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------