Subject: Re: XP question
From: Paul Rohr (paul@abisource.com)
Date: Mon Jan 31 2000 - 21:12:34 CST
Kevin,
You're thinking about adding sniffers to each importer, right? While
passing around FILE * is pretty generic, it still assumes that the content
being sniffed came from a filesystem using that API (instead of from a
network or the clipboard or something). Also, it assumes that you don't
have any rabid MacOS developers around, who like to use other APIs to troll
around inside the resource and data forks of a Mac file.
I do have to admit my bias here. In past lives, I've been on teams which
had to go through large codebases purging out existing assumptions about
being file-centric because the product needed to start running on hardware
which didn't *have* a filesystem. It's *much* easier to localize those
assumptions at design time.
In case any of these examples seem hypothetical, consider the following:
- importers (especially RTF) already *do* get used for our clipboard
- we've recently seen a new wave of developers interested in a Mac port
- Thomas is working on a QNX port, and QNX runs on some truly *weird*
hardware
Instead, I'd prefer to have each sniffer just be handed the same chunk of
memory containing a read-only copy of the first few K bytes of the file.
(IIRC, Caolan needs about 2200 bytes to accurately detect the right Word
version inside an OLE stream.) Obviously, the algorithms used in each
sniffer don't care whether they were handed that content as a file to be
opened vs. a const BYTE * (or UT_ByteBuf) chunk of memory. In fact the
latter code should be more compact.
Until someone comes up with a real *need* to have sniffer APIs become
file-centric, I'd strongly prefer that we avoid it.
Paul
This archive was generated by hypermail 2b25 : Mon Jan 31 2000 - 21:07:16 CST