Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!adobe!hawley From: hawley@adobe.COM (Steve Hawley) Newsgroups: comp.sys.mac.programmer Subject: Re: Is there a defacto standard for 'drop ins'? Message-ID: <13180@adobe.UUCP> Date: 25 Mar 91 18:07:00 GMT References: <1CE00001.aolmdnz@tbomb.ice.com> <13094@adobe.UUCP> Reply-To: hawley@adobe.UUCP (Steve Hawley) Organization: Adobe Systems Incorporated, Mountain View Lines: 54 In article d88-jwa@byse.nada.kth.se (Jon W{tte) writes: >You would rather want to get blocks at a time - like, > >typedef struct { > long amountToRead ; > long flags ; /* bit 0 == SetPosition supported &c */ > pascal OSErr ( * ReadBlock ) ( char * , long ) ; > pascal OSErr ( * PeekBlock ) ( char * , long ) ; > pascal OSErr ( * WriteBlock ) ( char * , long ) ; > pascal OSErr ( * SetPosition ) ( char * , long ) ; > pascal OSErr ( * TellUser ) ( char * ) ; >} filterParam ; Actually, I wouldn't want to get blocks at a time. The reason why I suggested a byte stream is that the parent program can decide what buffering scheme is most appropriate for the the drop-in module, and bytes streams will be free from typical problems associated with block reads: matching block size with ths OS for efficiency, byte ordering, word/long word alignment, what happens when I can't allocate a block size that I expected (do I put an alert? *CAN* I put up an alert? Am I allowed to move memory?) etc. It all depends on what you want, really. A stream oriented program is geared especially well for text and files and will work with a minimum of hassle with for many other applications as well. The outline of a stream based filter is straight forward and uncomplicated (for the most part -- there are always degenerate cases). It is simply easier to write a correct stream-based filter than it is to write a correct block-based filter, and you are forcing everyone who writes a drop in module to do their own buffer handling. If you have a program with a couple dozen drop-in modules, wouldn't you rather have the block buffering in one place than in 20? 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). So, back to the original question of "why is there no standard way for handling drop-in modules?" Do you have your answer now? Because no two people will ever agree on what is a "good" standard and the approach you take must be geared for the type of data you intend to be fiddling with. I'm glad I don't work on a standards committee... Steve Hawley hawley@adobe.com -- "Did you know that a cow was *MURDERED* to make that jacket?" "Yes. I didn't think there were any witnesses, so I guess I'll have to kill you too." -Jake Johansen