Subject: Re: [netatalk-admins] Netatalk and OPI
From: Hans-Guenter Weigand (hgweigand@wiesbaden.netsurf.de)
Date: Thu Jan 21 1999 - 15:24:11 EST
Rodger.Donaldson@wnl.co.nz wrote:
> On Tue, Jan 19, 1999 at 11:44:23PM +0100, Hans-Guenter Weigand wrote:
>
> > Do you refer to an OPI specification 2.0 or the Helios OPI 2.0 product?
>
> OPI spec 2.0.
URL available?
[Scanning the volume]
> Actually, it isn't that hard. And, moreover, tying the scanner to netatalk
> hurts portability (you'd have to have a whole 'nother bunch of integration
> for Samba, NFS, CODA access, for example), which in turn imapcts on
> utility[1].
Uh, yes, I forgot about NFS and the PC world. Helios Ethershare seems to
work like this: A file copied to the volume from a Mac instantly is
checked for type, and a layout file is generated if appropriate. If you
copy it there using NFS, you do not get a layout file. Their afp-daemon
notifies the opi-daemon, which forks and downsamples the image file. If
you bypass the afpd somehow, you have to touch the file from a Mac to
trigger the opid. This model offers prompt service to Mac users, but
obviously has some disadvantage.
> The main loop of the daemon should use a stat() on eached configured input
> directory, on only check the contents of the directory once the stat().
> That makes checking nice and lightweight. Stealing from the Colour Central
> model, a directory structure that looks like:
>
> sharepoint------> Inbound Files
> |
> |--> High-Res Files
> |
> |--> Low-Res Files
>
> ...allows me to keep the inbound queues low by moving hi-res files into
> another directory. Since I only have to traverse small directories, and
> only do it when a lightweight stat() tells me something has actually
> changed, it means the turnaround should be limited mainly by processing the
> low-res.
Prepress people here are used to a different model (which I would
prefer), which places the layout files into the same directory as the
hires files. "mypic.tiff" gets a little brother named "mypic.tiff.lay".
This makes it easier to handle both image and XPress (or PageMaker)
files in the same dir. If you separate the image files into different
dirs you make it more difficult to archive finished and printed jobs. An
average path looks like this in the ufs:
"<sharepoint>/<customer>/1998/<jobnumber>/". All files go into the
<jobnumber> folder, possibly with some subfolders. Once the job is done
its folder is put on CD and/or other media and deleted from the server
volume. There's never enough disk space ;)
> > The downsampled layout-file has to be available within a few seconds.
>
> Which requires some serious grunt 8).
>
> There are some intresting potential tradeoffs here; for example, one could
> have a single checking daemon which does a stat() every second, and if a
> change is recording, then determines what new files are present and then
> conditionally exec() a handler for it. The admin could then configure how
Can you give some impression of the time needed to find the new image
file in a, say, 100 GB ufs volume (with reduced number of inodes)? I'm
quite new to Unix programming and now little about wheels and gears
inside yet.
> many queues are available and how deep those queues are (do you allow one,
> two, three, or more items to be processed in a given queue).
Isn't it sufficient to start a downsampling process with nice +10 for
every detected new file? The kernel would have to handle "queuing" then.
> Anyways, all this talk inspired me to dig up the old code this morning. I
> took one look at it, threw most of it away, and am now happily banging away
> at FreePO[2] again.
Fine! Let me know if and how I may help. I run OpenBSD-current and
Solaris (2.)7 here, and MacOS of course.
> [1] For me, anyway; YMMV.
> [2] Free Perl OPI. Doubtless all the quick bits will be rewritten in C one
> day.
Isn't there some p2c utility, which does the dirty work?
-hgw
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:13 EST