Hi Jim,

> I'm losing my enthusiasm for compressed blobs. I'm not
> convinced the big win is there.

The tests you tried were interesting - in terms of having an
interesting cross-section of document types. I think that
your tests do prove that the potential benefits are fickle
enough to need compression to be at least optional - and
quite possibly a default of not-compressed would remain the
safest bet.

However, there are applications that could benefit more
significantly. Databases of html and other text data,
provided the blobs were of sufficient size to warrant the
compression, could see more significant gains.

But if the cost/benefit is not that great in the general
case I can certainly understand a drop in enthusiasm.
Perhaps this is something to be put on a "look at again in
a later version" list.

One of the things that this discussion has highlighted is
the potential need for a smarter blob-filter. A filter that
could be applied to the client so that data could be
transported to and from the client in an unfiltered form.

This could be a generic solution to the problem that we have
been discussing. Creation of such filters could then include
encryption, compression and perhaps other services. (Given
that arrays are essentially blobs, it is conceivable that
arrays could be managed via such filters rather than the
complicated API we currently use.)

I am not sure if such an idea would be practical, just a
thought inspired by these discussions.

--
Geoff Worboys
Telesis Computing