From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <775b8d190711302054g12c4868cv2575ab16c718a43c@mail.gmail.com>
Date: Sat,  1 Dec 2007 15:54:06 +1100
From: "Bruce Ellis" <bruce.ellis@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Ideas for an printer filesystem
In-Reply-To: <13426df10711302042x78d36291n54f50beb964aa068@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070906235628.GC26188@nibiru.local>
	<13426df10711302042x78d36291n54f50beb964aa068@mail.gmail.com>
Topicbox-Message-UUID: 0fa99210-ead3-11e9-9d60-3106f5b1d025

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
>