From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8ccc8ba40709070144y42f8c81andeb54dde4588f968@mail.gmail.com>
Date: Fri,  7 Sep 2007 10:44:34 +0200
From: "Francisco J Ballesteros" <nemo@lsub.org>
To: weigelt@metux.de,
	"Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Ideas for an printer filesystem
In-Reply-To: <20070906235628.GC26188@nibiru.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070906235628.GC26188@nibiru.local>
Cc:
Topicbox-Message-UUID: ba6afee2-ead2-11e9-9d60-3106f5b1d025

The octopus is using just an empty directory as the printer spooler.
(you may have as many as you want). When you start the fs you tell it the
underlying printing command and options. Thus, a simple cp suffices to print.

There are not too many print queues/options in actual use here to make it
unpleasant.

hth

On 9/7/07, Enrico Weigelt <weigelt@metux.de> wrote:
>
> 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/
> ---------------------------------------------------------------------
>