Re: [netatalk-admins] Netatalk and OPI


Subject: Re: [netatalk-admins] Netatalk and OPI
From: rodgerd@wnl.co.nz
Date: Wed Jan 20 1999 - 02:15:27 EST


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.

> > The first function is really the job of a daemon scanning directories for
>
> Actually this is the main problem IMHO. There has to be a way to inform
> the OPI process that a user has put a file into the server volume.
[...]
> So scanning a volume doesn't work here. This would take tens of minutes
> until a new file is discovered, since OPI server volumes nowadays range
> from 60 to 200 GB and more.

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

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.

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

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.

[1] For me, anyway; YMMV.
[2] Free Perl OPI. Doubtless all the quick bits will be rewritten in C one
    day.

-- 
Rodger Donaldson			rodger.donaldson@wnl.co.nz
Systems Support				Direct line	: 04 474 0560
Wellington Newspapers Limited		Fax		: 04 474 0309
You are in a maze of twisty little companies, all working against each other.



This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:12 EST