--- Jim Starkey <jas@...> wrote:

> I'm afraid images, PDFs, Excel files, zip files, jpegs, and anything
> encrypted are a) part of the landscape, and b) compressed because
> other people saw the value in compression and beat us there.
>

I don't know if my situation is at all typical, but my requirements
managment program's primary data is a large (over 10,000 so far) number
of requirements and issues described in memo fields using an RTF memo
component (WPTools). The component allows pictures to be embedded.
Using the simplest method, which is to do an Alt+PrintScreen and then a
paste, these get embedded in the RTF blobs as bitmaps. Sometimes the
screen shots make these memo fields grow to as much as 10MB.

The result is that the fdb file is up to 1,150MB, but the fbk files zip
down to just over 80MB. There is a LOT of headroom there for compressed
blobs to make a huge difference for my app- and to dramatically speed
up the opening of requirement records if the decompression is done on
the client.

I already have plans to replace the DB aware component with the non-DB
one, and add my own compression on the client, but it would be GREAT if
the FBClient.dll handled that automatically.

Personally, I would be happy with three blob types- text, subject to
search with "containing"; Octets, not searchable with Containing but
perhaps seekable (although that makes no difference to me), and then
Compressed, which would be a "black box"- not searchable, indexable, or
anything else. The only difference between the latter two would be
whether or not the client does the compression and decompression when
the field is referenced.

Just my 2 cents- as I said, I'll probably get around to implementing my
own compression logic long before FB3 comes out with or without
compression built-in, so it doesn't matter too much for me.