paulruizendaal wrote:

>>> And if this mega-provider is ever implemented, what will be a
>>> reason of using other providers directly? Why not pass all queries
>>> through it?
>>>
>>>
>> That a possibility.
>>
>
> It certainly is, and those that are too lazy to study history are
> bound to repeat its mistakes.
>
> It would be good to study the Oracle experience and the Ingres
> experience. Have a look at, for instance:
> http://www.cc.utu.fi/static/ingres/STARUG.PDF
> for an example of Jim's mega-provider, and at for instance:
> http://www.lc.leidenuniv.nl/awcourse/oracle/server.920/a96540/statements_56a.htm
> for an example of going the rse route.
>
> At one point in time, the Ingres folks were building Star as a
> separate project. Then they belatedly figured out that Star actually
> contained >80% of the code of a regular Ingres instance and they
> reverted to building it from the same code base. A bit like we build
> Classic and Super from a single code base.
>

Paul, I'm going to have to differ here. The engine was designed as a
multi-client from the alpha of version one, and became a multi-client,
multi-threaded server when threads started showing up on platform
operating systems. Charlie consolidated the multi-threading code into
Superserver by building a process local "latch" mechanism as an adjunct
to the lock manager. All that was years before it was released open
source. You, sir, didn't have anything to do with it. So let's be a
bit careful about what we take credit for, shall we?

And, frankly, I don't think the joint Superserver/Classic decision was a
good one. Once the decision to take the engine out of the process
address space, the classic architecture makes no sense. It would have
been better to make the server 100% process based, get rid of the lock
manager, shrink the engine by 50%, and make it run like a bat out of
hell. Conditional code is usually a way to do two separate things, each
badly. If Superserver had been done well, classic wouldn't need to
exist for anything but embedded used, and maybe not even then.

> If one thinks it through, it soon becomes apparent that "building a
> mega-provider" and "solving it at the rse level" actually results in
> much the same code design.
>

Really? The mega-database manager has just as much in common as Falcon
(maybe more) than it has to Firebird or Vulcan. Yet Falcon has a
radially different architecture than Firebird / Vulcan. If your
argument were true, then Falcon and Vulcan would be the same design,
which I assure you it is not (hopefully you can look for yourself in the
near future).

> So the whole debate around Jim's argument simplifies to:
> - which presentation to the user is easier to understand
> - is calling back into the provider chain from a regular server (using
> all the proper interfaces) 'breaking the architecture' (as compared to
> calling back into the provider chain from a special mega-provider build)?
>

I've written three commercial RDMSes and one data distributor, so I
think I have a little insight into the problem. The RDMSes and the data
distributor start with parse and semantic analysis, then diverge
radically. You can, of course, make a combination toaster / lawn mower
if you wish. It will, however, be both a bad toaster and a bad lawn mower.

> Paul
>
> BTW, where did the "quadruple in complexity" insight come from? Do you
> have any references for that insight?
>

Oh, I'd say it came from 30 years of writing database management
systems. But here's the arithmetic: First, there's the original
complexity. Second, there's the complexity of new functionality.
Third, there's the additional complexity to know when to apply one and
when to apply the other. Fourth, there are the 10,000 nasty little
places where there are implicit assumptions that you're only dealing
with one database.

But, putting all that aside, if you could consider taking the time to
talking about the requirements for a cross database data manager, I
think the issues would work themselves out quickly and simply. The
problem, Paul, is that you want to put the design and implementation
before establishing the requirements. Maybe you don't actually need a
combination toaster / lawn mower. Maybe you need an appliance
management system that contains, optionally, toasters and lawn mowers as
plug-ins.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376