On Sep 6, 2007 6:56 PM, Enrico Weigelt <[EMAIL PROTECTED]> 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
