Dmitry Yemanov wrote:

>> 3. Blob compression is problematic with blob seek, and an acceptable
>> compromise must be found, though the compromise may require a
>> per-blob compromise
>>
>>
>
>Let's discuss the possible compromises.
>
>

I'm getting ready to punt on this question and suggest that we require
that blobs that support blob seek be declared as uncompressed or the
moral equivalent. If somebody needs to ability to interact with inner
block structure he should be willing to forgo the optimization of
compression. Whether or not this is actually necessary, it does shift
the burden to the advocates of blob seek.

>
>
>> 4. Client side compression and decompression has the double benefit
>> of reducing the server CPU load while reducing the number of byte
>> and packets transmitted over the wire
>>
>>
>
>First, this means that no pluggable algorithms are possible, as you already
>mentioned. Personally, I can live with this. Second, it brings enough issues
>for the single PC usage including the embedded one. Why do I need a good
>over-the-wire compression if I have no wire at all? Did you also consider
>e.g. Pocket PC usage (with much slower CPUs)?
>
>

A client can choose not to compress. Simple enough?

>Agreed. Should temporary blobs to be also compressed when sent to the
>client?
>
>

I don't see any reason why not. The new API needs to support blobs
originating from setBlob, setBytes, setText, etc. But we also need to
be able to continue to support staged blobs. I don't see any problems
with compressing any or all of the above. There is a question, however,
as to whether the compression information is part of the staged blob or
a compression prefix on edsBlobIdxxx. If somebody knows the answer, I'd
like to hear it.

>Too many builtin [de]compression algorithms complicates the client library.
>Do you want them to be linked-in or loaded dynamically (i.e. some predefined
>set of plugins)?
>
>

We've lived with no compression on blobs and run length encoding in
records for 20 years. I'd be perfectly happy to audition the existing
schemes that are license compatible with Firebird and pick one that
conforms to our best appreciation of tradeoffs and live with it. In
five to ten years somebody will come up with a better one, and we can
add a second.

Based on my current prejudices, I'd pick zlib. I'd argue that we should
modify it to support a static alphabet tuned for our data stream
encoding and utf-8. Then someone will point out that a modified
algorithm will make it impossible to use the AMD decompression
instruction, and we should stick to the straight and narrow. I'll
counter that AMD doesn't actually have that instruction, and basing an
architecture on an industrial rumor isn't smart. Then Intel will
annouce a chip set to do run length encoding with an ISA board for
Claudio's 486 and I'll have to eat my words.

>
>
>>It also makes compromises to support
>>blob seek problematic.
>>
>>
>
>And this is what we must solve.
>
>I see the only solution - add a new blob type (which is independent from
>streamed/segmented). I mean a new BPB option - compressed/not compressed.
>The default behaviour (no option is specified) is either hardcoded or
>settable via the config file. With a default set to compressed, we have all
>the benefits of Jim's proposal, but it still keeps other usage options
>possible. This solution solves all needs and costs us virtually nothing from
>the implementation POV.
>
>

See above.

>Questions:
>
>1) what should a blob seek do for a compressed blob? Decompress in server's
>memory or return an error?
>
>

Check the cpu type. If 486, it should short the address lines of the
memory bus to 110/220 volts and fry the sucker. On other machines it
should check for user name. If "Roman" it should throw an exception,
other decompress in memory.

>2) how should temporary blobs be transfered? Inherit the compress option
>from its persistent source? Use a config setting?
>
>
>

I await your comments.


[Non-text portions of this message have been removed]