Subject: Re: [netatalk-admins] Netatalk and OPI
From: Hans-Guenter Weigand (hgweigand@wiesbaden.netsurf.de)
Date: Fri Jan 22 1999 - 19:48:02 EST
Rodger.Donaldson@wnl.co.nz wrote:
> On Thu, Jan 21, 1999 at 09:24:11PM +0100, Hans-Guenter Weigand wrote:
> > Uh, yes, I forgot about NFS and the PC world.
>
> Something many people would like tro be able to do 8).
As you see, I sometimes really do. It's easy, just try! Start by sitting
down in front of a Macintosh. :)
> Quite. As I indicate, I think we can offer prompt service on a cross
> platform basis to everyone, which would be the ideal. Reading your
> description did get me thinking about optimal ways of downsampling though;
> previously, I'd just worked from the notion that one does a downsample from
> a big file. Thinking about how Helios could be hooking into their afpd
> analogue for more speed got me onto a slightly better (and should have been
> more obvious): checking the resource fork and the PostScript for embedded
> previews. That way, one could deliver low-res samples with pretty
> impressive speed; we'd only bog down on files that don't have a preview
> already.
But only if the preview matches the settings for the layout file. If you
just downsample a tiff file from 300 to 72 dpi you get a really small
file, but you lose quality. It is better to use jpeg with some low
quality, because it gives you the same file size, but a much better
quality for the low-res file, or a smaller file with the same quality as
the 72 dpi tiff.
BTW, Helios has a nice feature to adjust the resolution of the low-res
files. If a folder's name ends with '%36', all files generated in this
folder and every folder below have 36 dpi, '%0' suppresses the
generation completely. If someone works with poster size pictures, 18
dpi is really enough.
> > An average path looks like this in the ufs:
> > "<sharepoint>/<customer>/1998/<jobnumber>/". All files go into the
> > <jobnumber> folder, possibly with some subfolders.
>
> Does this mean that you have the Helios OPI watching every job folder? In
No, it watches the whole volume(s) automatically. There is no way to
configure anything.
> that case, I can can see the value in hacking the afpd analogue to talk to
> the sampler, because that would get a little more awkward without
> co-operating with it. Not impossible, but it would be harder to implement
> elegantly.
It would make more sense to hack the kernel's fs code. This makes it
compatible with NFS, samba and friends. But I think it is not worth
trying, it is completely unportable.
> > 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.
>
> Depends on whether you search the whole hierarchy or not; I also don't have
Whole volume, i.e. shared folder respectively...
> a UFS volume handy. I'll get some times across some 10-24 GB ext2 fses over
> the weekend, and take it from there.
ext2fs should be OK, since it is mostly a reimplementation of the
Berkeley ffs used by all *BSD variants. ffs is called ufs in Solaris.
The main difference between ffs and ext2fs IMHO is the asynchronous
writing of meta information. This can be turned on in ffs, but is
discouraged. I never lost files on a ffs even when the machine crashed
every five minutes. But ext2fs under Linux once lost many files after a
single crash and forced me to reinstall. So ext2fs is somewhat faster,
but a bit unsafe. I would never use it in a production environment. This
is not a prejudice, just experience.
> > 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.
>
> That's one way; OTOH, one may want to specify some queues as more equal
> than others - you might have a queue set up for people who are scanning
> work a few days in advance (something we do here, begin a newspaper),
> where the ability to get everything sampled all at once, as quickly as
> possible, is lower priority.
Queueing meens to make it more complicated for the users. Keep it as
simple as possible. Actually, an OPI-server needs to have enough CPU
power. That's the way we make our living by selling big machines. :)
But I do not completely understand how you want do manage queuing. How
does it look to the user?
> > Isn't there some p2c utility, which does the dirty work?
>
> That's a pascal to C translator. There's not actually that collosal a
I meant a Perl-to-C translator. Forgot about Pascal, sorry! ;)
> difference between Perl and C for a lot of work; moreover, for a lot of the
> work being done here - mucking about with PostScript streams - perl most
> likely handles the text involved better than any C I can write ever will.
> The filesystem stuff may be a different matter.
Can't Perl call compiled modules written in C? I think I read about this
somewhere.
> I'll spend some time hacking over the weekend and make the results
> available early next week. We should probably take the discussion away from
> netatalk-admins, unless we start trying to integrate stuff into netatalk,
> although I don't have a listserv of my own.
OK. Reply-to set.
-hgw
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:14 EST