I've been through quite a few what we currently call paradigm shifts in
the computer business: Timesharing to departmental computing to
networked workstations to client-server computing to the Internet.
Throughout the entire process, the database community has consistently
been on the extreme trailing edge of technology. I've usually
characterized the database community as pigheaded and short sighted,
though a more generous appraisal might say they database guys are
inherently conservative with great reverence for established authority.

At the time I design DSRI, the big battles were over whether the API
would support distributed computing and whether or not blobs would be
supported. The DEC database establishment -- the VAX DBMS (codasyl)
were strong believers in central computing with terminals radiating
outward, and while networking was good for email and copying files, not
really a database issue. If a single machine wasn't enough, then a
cluster was the answer. On the blob front, the argument was that none
of the competitors had blobs, no customer had ever asked for a blob, and
DEC had never lost a sale because we didn't have blobs.

Well, distributed computing and blobs won out in the end. But while
the technology and the cast of characters has changed, the attitude and
mindset has remained. The database community continues to insist that
client server computing is here to stay and the Internet is just a big LAN.

Friends, it ain't so. Client server computing doesn't scale, isn't
secure, and will (and must) die. And the Internet is most assuredly not
just a big LAN.

When I hear Sean oppose multiple roles, I hear the echo of Steve Klein
explaining why blobs don't belong in databases. They aren't sanctioned
by authority, we don't need them, their absence can be worked around,
etc. But Steve's world of central computing is dead and gone, and
Sean's world of client server computing is doomed. Our brave new world
of Internet computing starts with search (utterly ignored by the
database community) and third party security controls (actively opposed
by the database community).

I once had hopes that Firebird could again become the hot bed of
database technology. Interbase pioneered heterogeneous connectivity,
cascading triggers, UDFs, blob filters, events, cross product gateways,
two phase commit, multi-generational architectures, and much more.
There is just as much work to be done to meet the data management needs
for the next 20 years, but I have come to recognize that it isn't going
to happen at Firebird.

So, I give. Sean, you win. Multiple roles aren't needed for client
server computing. When the standard or other products adopt them, we
will have plenty of time to catch up then. There is no reason to get
hot and bothered about pushing the state of the art for a project mired
in the past.

Let's make Firebird the best archaic database on the planet. When the
SQL committee or Microsoft show us the way, then we can follow.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376