[9fans] Ideas for an printer filesystem

[9fans] Ideas for an printer filesystem

[Enrico Weigelt]

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/
---------------------------------------------------------------------

Re: [9fans] Ideas for an printer filesystem

[Francisco J Ballesteros]

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/
> ---------------------------------------------------------------------
>

Re: [9fans] Ideas for an printer filesystem

[erik quanstrom]

> 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.

how do you keep the printer from starting on a job too soon?

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

are you still using lp under the covers?

- erik

Re: [9fans] Ideas for an printer filesystem

[Francisco J Ballesteros]

The fs does not issue the print command until the descriptor being
used to update
file contents is closed.

And yes, on Plan 9, lp is used. On macosx, lpr.


On 9/7/07, erik quanstrom <quanstro@quanstro.net> wrote:
> > 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.
>
> how do you keep the printer from starting on a job too soon?
>
> > There are not too many print queues/options in actual use here to make it
> > unpleasant.
>
> are you still using lp under the covers?
>
> - erik
>
>

Re: [9fans] Ideas for an printer filesystem

[erik quanstrom]

> The fs does not issue the print command until the descriptor being
> used to update file contents is closed.

ah.  the print directory is not any old directory, but a special fs.

> And yes, on Plan 9, lp is used. On macosx, lpr.

unfortunate.

- erik

Re: [9fans] Ideas for an printer filesystem

[Aki Nyrhinen]

On Sep 7, 2007 12:54 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> > The fs does not issue the print command until the descriptor being
> > used to update file contents is closed.
>
> ah.  the print directory is not any old directory, but a special fs.
>
> > And yes, on Plan 9, lp is used. On macosx, lpr.
> unfortunate.

i think so too. gs(1) is the guy who does all the work for home
class printers, so i've never set up lp (it's too damn hard and it's
functionality would be mostly useless anyway!). instead, i've
been happy to type a gs command into a script. it's something
like (can't really check now)

gs -dNOPAUSE -sDEVICE=hl7x0 -sOutputFile=/dev/lpt1data -q -dBATCH $1

this seems to work with a higher success rate than cups on the
linux distribution of the day. configuration consists of changing
the strings hl7x0 and lpt1data to something that works for you.
if the printer is old and bad and has too little memory, add -r300
or similar to print in bigger dots.

could be you need to recompile plan9 gs, it has reduced support
for printers per default.

i can imagine it'd be easy to make nemos print spooler to exec
a script instead of lp. the script could exec that gs command or
dial tcp for networked or do spam filtering.

Re: [9fans] Ideas for an printer filesystem

[Enrico Weigelt]

Hi folks,

I've written a few ideas into my wiki:

http://oss-qm.metux.de/index.php/9forge/printfs

Feel free to contribute.

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/
---------------------------------------------------------------------

Re: [9fans] Ideas for an printer filesystem

[Francisco J Ballesteros]

Seem just too complex to me (the interface, I mean).

Wouldn't just a directory where files to be printed can be copied suffice?
You can still get a ctl or status file for the directory for control
commands and
status reports.

On Nov 30, 2007 4:37 AM, Enrico Weigelt <weigelt@metux.de> wrote:
>
> Hi folks,
>
> I've written a few ideas into my wiki:
>
> http://oss-qm.metux.de/index.php/9forge/printfs
>
> Feel free to contribute.
>
>
> 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/
> ---------------------------------------------------------------------
>

Re: [9fans] Ideas for an printer filesystem

[Enrico Weigelt]

* Francisco J Ballesteros <nemo@lsub.org> wrote:

Hi,

> Seem just too complex to me (the interface, I mean).
> 
> Wouldn't just a directory where files to be printed can be copied suffice?

No, I dont think so.
Only copying one file is not enough, otherwise you have no chance
for giving additional parameters like colorspace, orientation, 
resolution, etc, etc, etc. The application would have to handle all 
this by itself and would require more detailed information about the 
printer (which would tie the job to one specific printer).

And I dont think its too complex. Starting a job is still simple:
Just create a job dir, upload the content and write your parameters
to the appropriate files.

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/
---------------------------------------------------------------------

Re: [9fans] Ideas for an printer filesystem

[Rodolfo =?unknown-8bit?Q?Garc=EDa?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1822 bytes --]

"Probably" you need three files:

1. The printer job, for example the .ps file
2. The printing options (orientation, ...)
3. The printer options (Filters, drivers, ...), in the printer directory

The printing options can be set with 'echo "A4,300ppp,protrait" >
/printers/LaserJet-A/ctl' The printer options must be in a file, and then you can print with something like 'cat myfile.ps > /printers/LaserJet-A/data'

Saludos.

On Fri, 30 Nov 2007, Enrico Weigelt escribió:

> * Francisco J Ballesteros <nemo@lsub.org> wrote:
> 
> Hi,
> 
> > Seem just too complex to me (the interface, I mean).
> > 
> > Wouldn't just a directory where files to be printed can be copied suffice?
> 
> No, I dont think so.
> Only copying one file is not enough, otherwise you have no chance
> for giving additional parameters like colorspace, orientation, 
> resolution, etc, etc, etc. The application would have to handle all 
> this by itself and would require more detailed information about the 
> printer (which would tie the job to one specific printer).
> 
> And I dont think its too complex. Starting a job is still simple:
> Just create a job dir, upload the content and write your parameters
> to the appropriate files.
> 
> 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/
> ---------------------------------------------------------------------

-- 
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/

Re: [9fans] Ideas for an printer filesystem

[Enrico Weigelt]

* Rodolfo García <kix@kix.es> wrote:
> "Probably" you need three files:
> 
> 1. The printer job, for example the .ps file
> 2. The printing options (orientation, ...)
> 3. The printer options (Filters, drivers, ...), in the printer directory
> 
> The printing options can be set with 'echo "A4,300ppp,protrait" >
> /printers/LaserJet-A/ctl' The printer options must be in a file, 
> and then you can print with something like 'cat myfile.ps > /printers/LaserJet-A/data'

Thats not an good idea, since here you set the parameters for the whole
printer, not just for a single job. 


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/
---------------------------------------------------------------------

Re: [9fans] Ideas for an printer filesystem

[Rodolfo =?unknown-8bit?Q?Garc=EDa?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1606 bytes --]

Then you can split the process,

First, create the final ps-like-file, ready to print. Something like
print to file. Like mpage in Linux.
Second, copy the ps-like-file to the printer.

Example:

file2print -portrait -2pagesperpage -bpp300 -input acme.ps -output acme-toprint.ps
cp acme-toprint.ps /printer/myprinter/spool/

Is an idea.


On Fri, 30 Nov 2007, Enrico Weigelt escribió:

> * Rodolfo Garc?a <kix@kix.es> wrote:
> > "Probably" you need three files:
> > 
> > 1. The printer job, for example the .ps file
> > 2. The printing options (orientation, ...)
> > 3. The printer options (Filters, drivers, ...), in the printer directory
> > 
> > The printing options can be set with 'echo "A4,300ppp,protrait" >
> > /printers/LaserJet-A/ctl' The printer options must be in a file, 
> > and then you can print with something like 'cat myfile.ps > /printers/LaserJet-A/data'
> 
> Thats not an good idea, since here you set the parameters for the whole
> printer, not just for a single job. 
> 
> 
> 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/
> ---------------------------------------------------------------------

-- 
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/

Re: [9fans] Ideas for an printer filesystem

[Anant Narayanan]

> Only copying one file is not enough, otherwise you have no chance
> for giving additional parameters like colorspace, orientation,
> resolution, etc, etc, etc. The application would have to handle all
> this by itself and would require more detailed information about the
> printer (which would tie the job to one specific printer).

How about simply:

$ echo "print <printing-options> <printer-options>" > /printers/ctl
$ cat myfile > /printers/data

Skipping either the printing/printer options while writing to ctl  
will result in default options being applied.

--
Anant

Re: [9fans] Ideas for an printer filesystem

[Lucas James]

On Sat, 1 Dec 2007 03:46:46 Anant Narayanan wrote:
> How about simply:
>
> $ echo "print <printing-options> <printer-options>" > /printers/ctl
> $ cat myfile > /printers/data
>
> Skipping either the printing/printer options while writing to ctl
> will result in default options being applied.
>
> --
> Anant

That's only good for single machine/single user setup.  

If you have more than one person/program trying to print to different 
printers/options, you would get mixed results.  Picture a second print job 
starting in between the write to /printers/ctl and /printers/data, and you'll 
see the difficulties in keeping it all together.

Lucas

-- 
Modern man is the missing link between apes and human beings.

Re: [9fans] Ideas for an printer filesystem

[ron minnich]

On Sep 6, 2007 6:56 PM, Enrico Weigelt <weigelt@metux.de> wrote:

>     /next-id               spits out an new (random) job-id

it's the wrong place. I think you need /jobs directory, with a /jobs/clone.

You open /jobs/clone, it's a ctl file. You copy the file to that dir.
you attach the job to the printer much the way you attach a protocol
stack to an interface.

i suggest your best bet is to try to put something together and see
what feels right. Abstract design is no substitute for prototyping and
experience with prototypes.


>
> 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

you'll almost certainly not cover all the info you need with all the
file names. Why not do as the network stack does and have status,
which returns this info as a set of tuples -- want to guess what
format I'd like? (hint -- it's NOT XML)


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

options should attach to jobs, not to printers. Else you have the
possibility of a nice combinatorial explosion.


> * Creating a new job:
>   + fetch a new job-id

cat /job/clone

>   + mkdir a new job queue entry (with fetched key)
no no no. :-)

>   + all necessary structures will appear automatically
>   + upload the postscript data to ./content.ps
>   + do appropriate changes (ie. papersize, orientation, colorspace, ...)
>   + write "new" to ./status

eek. Have a ctl file.
>
> * Abort an job
>   + look for the job's dir and write "abort" to ./status
no. ctl file.


> What do you think about this ?

Study the network devices, they're pretty nice.

ron

Re: [9fans] Ideas for an printer filesystem

[Bruce Ellis]

i wrote a clonefs that changes a walk to the directory created for
the server to an attach  with ctl.  it saves a lot of replicated code.
i wonder what happened to it.  it's not too hard.

brucee

On Dec 1, 2007 3:42 PM, ron minnich <rminnich@gmail.com> wrote:
> On Sep 6, 2007 6:56 PM, Enrico Weigelt <weigelt@metux.de> wrote:
>
> >     /next-id               spits out an new (random) job-id
>
> it's the wrong place. I think you need /jobs directory, with a /jobs/clone.
>
> You open /jobs/clone, it's a ctl file. You copy the file to that dir.
> you attach the job to the printer much the way you attach a protocol
> stack to an interface.
>
> i suggest your best bet is to try to put something together and see
> what feels right. Abstract design is no substitute for prototyping and
> experience with prototypes.
>
>
> >
> > 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
>
> you'll almost certainly not cover all the info you need with all the
> file names. Why not do as the network stack does and have status,
> which returns this info as a set of tuples -- want to guess what
> format I'd like? (hint -- it's NOT XML)
>
>
> > * Cloning a printer (to have multiple instances w/ separate options):
> >   choose some name and write it to ./clone
>
> options should attach to jobs, not to printers. Else you have the
> possibility of a nice combinatorial explosion.
>
>
> > * Creating a new job:
> >   + fetch a new job-id
>
> cat /job/clone
>
> >   + mkdir a new job queue entry (with fetched key)
> no no no. :-)
>
> >   + all necessary structures will appear automatically
> >   + upload the postscript data to ./content.ps
> >   + do appropriate changes (ie. papersize, orientation, colorspace, ...)
> >   + write "new" to ./status
>
> eek. Have a ctl file.
> >
> > * Abort an job
> >   + look for the job's dir and write "abort" to ./status
> no. ctl file.
>
>
> > What do you think about this ?
>
> Study the network devices, they're pretty nice.
>
> ron
>

Re: [9fans] Ideas for an printer filesystem

[roger peppe]

On Dec 1, 2007 4:54 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> i wrote a clonefs that changes a walk to the directory created for
> the server to an attach  with ctl.  it saves a lot of replicated code.
> i wonder what happened to it.  it's not too hard.

i'm not quite sure what you mean here. do you mean something
like a filesystem that layers over (for instance) /net, so doing

    walk(net/tcp)

actually does

    id = open(/net/tcp/clone)
    walk(/net/tcp/id)

?

how do would you then open a file in the new directory
wthout going doing the same thing (and hence writing
to a different directory)?

Re: [9fans] Ideas for an printer filesystem

[Bruce Ellis]

No - that's would be adding a another clone interface to a driver that
has a clone interface.  I'll see if I can find the man page.

On Dec 12, 2007 12:30 AM, roger peppe <rogpeppe@gmail.com> wrote:
> On Dec 1, 2007 4:54 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> > i wrote a clonefs that changes a walk to the directory created for
> > the server to an attach  with ctl.  it saves a lot of replicated code.
> > i wonder what happened to it.  it's not too hard.
>
> i'm not quite sure what you mean here. do you mean something
> like a filesystem that layers over (for instance) /net, so doing
>
>    walk(net/tcp)
>
> actually does
>
>    id = open(/net/tcp/clone)
>    walk(/net/tcp/id)
>
> ?
>
> how do would you then open a file in the new directory
> wthout going doing the same thing (and hence writing
> to a different directory)?
>