Newsgroups: comp.sys.mac.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Subject: Re: Is there a defacto standard for 'drop ins'?
Message-ID: <e+-bi2.qf8@smurf.sub.org>
Date: Wed, 27 Mar 91 19:21:10 GMT
References: <13094@adobe.UUCP> <D88-JWA.91Mar24213927@byse.nada.kth.se> <13180@adobe.UUCP>
Organization: University of Karlsruhe, FRG
Lines: 26

In comp.sys.mac.programmer, article <13180@adobe.UUCP>,
  hawley@adobe.UUCP (Steve Hawley) writes:
< 
<The down side (as I mentioned before) is that you pay for a function call for
<each byte you read.  Obviously, for something like filtering of, say, 24 bit
<graphics data, a stream-oriented method is going to be extremely painful.  In
<fact, so will a block-oriented method unless the only block that gets passed
<is a pointer or handle to a data structure describing the data (like a PixMap).

You could conceivably get the best of both worlds by also passing a parameter
on how many bytes to read. The drop-in module should of course be able to
handle partial reads.

If you want to get fancy, pass another parameter to flag that the application
should stop after the first CR, thus implementing line-at-a-time reads.

It might also be a good idea to lock the buffer and pass its address back to
the filter instead of copying the data into the filter's buffer; most filters
can't read into their final data structure anyway -- a filter's job is to
convert data, right?

How do existing filter interfaces (Claris, Stuffit) handle these problems?

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330)   \o)/