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

>
> 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.

Fine.

> A client can choose not to compress. Simple enough?

Of course ;-)

> >Agreed. Should temporary blobs to be also compressed when sent to the
> >client?
>
> I don't see any reason why not.

Okay, I also agree here.

> 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.

Could you please elaborate what you mean here?

> 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.

Fully agreed.

> >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.

Does it mean we're on the same line of thinking or have I missed some turn
of your thoughts?

> >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.

LOL ;-)

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

If we use a BPB flag, then a compression type is an attribute of a
particular blob instance. The lowest level of control, although I'm not sure
whether we need two rows having their blobs compressed differently? If this
doesn't make much sense in practice, then we should use some blob column
flag as a compression type. Or is it feasible to have three levels of
control: blob instance (via BPB) -> column (via RDB$FLAGS) -> config entry?
I doubt this is necessary, but I don't use blobs much in my apps, so let's
others decide.

We need to decide about the compression control - column or blob instance
level (see above) - before going further. It mostly dictates rules on how
something should be stored and transmitted over the wire. As for whether a
server generated temporary blob should be compressed or not before being
either materialized or transmitted, I don't have any strong preference.
Let's just default to the global setting (i.e. config option)?


Dmitry