Some thoughts...

We need to be wary about what assumptions are made about the
future of hardware. It can change incredibly quickly, but it
can also take a surprisingly long time. Predicting exactly
what things will come to fruition and when, is a fools game.

I have kept a casual eye on solid-state hard disk drives for
several years now. The concept, but apparently not the
available technology, had the possibility of changing the
landscape for database development. SSDs are still around,
many years after their initial appearance, but cost and the
current technology has kept their impact to a minimum. The
other curiousity was to see that major HDD manufacturers that
originally supported the concept seem to have let it go.

BUT a relatively small technological break through could bring
SSDs back into the limelight quite quickly.

A similar example exists with DVD. I waited what seemed to be
years for DVD writers to appear in the mainstream. In this
case it seemed to be "standards" rather than technology keeping
their appearance at bay. Then suddenly the situation changed
(I dont really understand why), and now it seems most new PCs
are coming with CD/DVD writers.

I am sure that there are many, many other examples. These are
just a couple off the top.

The moral of the story is that development really needs to be
concentrated in the here and now. Sure, we keep an eye on what
may be coming and try to enable our developments to take
advantage in such areas, but to base success on what _may_
appear is a risky business.


Another aspect is to remember the target audience. One of the
reasons (and marketing points) for the success of Interbase and
Firebird has been its "small footprint". Included in that has
been its ability to run on systems that are just not suitable
for other products. For example a recent client has installed
their "server" on the workstation also being used one of the
staff. Sure performance and stability may be impacted, but for
a network of only half-a-dozen users this was not a major
consideration.

If a new version of FB *requires* multi-Gb of RAM just to be
able to run then we will alienate many users. ("requires" is
different from being able to "take advantage of" - which FB
must be able to do.)

This is not to say that we should develop for 8086 with just a
few Kb of RAM. But a level of compromise is needed. The
targetted platforms will obviously rise with each new version,
and this is appropriate. The trick is to try and keep the
target in mind.


It is my belief that Firebird needs to be "scalable" and also
to have a possibly "small footprint". As such it is important
that it runs on relatively low-resource machines (in todays
terms, not in the terms of 20 years ago). It must be able to
scale down as well as up!

The compromises required to support such scalability may mean
that we fail to be as completely fast as possible at either end
of the scale. But as long as it is fast enough (a very loose
and subjective phrase) the speed is less important that the
ability to operate effectively over the range of targets.

To date Firebird (and before that Interbase) has managed to
pull off the compromises required - although its ability to
scale upwards into SMP has suffered.


And to come back onto topic a bit more, all this means to me:

To have a version of Firebird that requires blobs be loaded in
full into memory on the server is a mistake. Such an approach
is likely to require machines with a level of memory not
compatible with the _current_ low end targets.

To have a version of Firebird that forces sophisticated high
level compression on all blobs is also likely to impact low
end machines. When the FB server process is sharing resources
with a user or other server procecess the excess (and often
redundant - eg: jpg) CPU cycles could be a potentially fatal
performance impact.

Another idea I saw mentioned was one type of compression for
storage with a potentially different compression used for
communication. So what? We are going to have the server do
decompression from storage and then recompression for
transport? This was a joke, right?

**IF** Firebird is to support compression for blobs it needs
to be configurable per blob column. So that it can be turned
off when undesirable (wanting to search blobs, or when storing
jpegs and other precompressed data). Ideally such compression
should carry directly across the wire - with the client doing
the decompression on receipt. If an SQL search occurs on such
blobs the worst that happens on the server is decompression to
test the search criteria - and then the already compressed blob
is sent with no recompression required.


But... How important is it that FB actually does compression
on blobs? I can understand needing to compress other fields,
and especially indexes, to increase performance in other ways.
But in terms of used disk storage and network performance there
are other answers already available - no need to wait for new
technology.

I believe that IB/FB has had the right approach so far. Leave
such things as compression and encryption to external services.
We already have operating systems services for on-the-fly
encryption and compression. Similarly there are network
services to fulfill the same requirements. (Note that
encryption also provides compression.) The real advantage of
these external services include:

- they are user configurable; can be turned on/off as per
the needs of the particular installation, with users
choosing an implementation that best suits them.

- they work for other things besides FB; so users can
configure ONE service and have the advantage across
all their applications.

So why does FB need to repeat what is already available in
tested, stable and efficient implementations?

Anyway, thats the way that I see it.

--
Geoff Worboys
Telesis Computing