m_theologos wrote:

> --- In Firebird-Architect@yahoogroups.com, "Ann W.
> Harrison" <aharrison@...> wrote:
>
>> There have been designs for it for decades. There is a practical
>> problem however, which is optimization. We currently optimize to
>> minimize the number of records in the intermediate data sets.
>>
>
> Agree. But I think that is much more important to have _now_ simple
> (not simplistic) working features with a good field of improvement
> (in order to attract users), rather than to have a perfect feature
> after, let's say, 3 years. (See also the Paul Ruizendaal's message)
> IMHO, perhaps is better to support in the next version the most
> common case, which is, I think, the most simplest ie. all databases
> locally on a superserver architecture, eliminating in this way the
> communication problems and also having the advantages which Adriano
> dos Santos Fernandes pointed out (the same address space, easy to
> find structs aso.).
>

Are you suggesting that we implement a dumb-ass, non-extensible design
that solves 15% of the problem and can't be extended to the remaining
85%? It's not like this hasn't been thought about and discussed. We'd
be a happy to go over the issues if you'd like, but waving your hands
and suggesting that they can be ignored doesn't strike me as a
particularly smart way to proceed.

Adriano is currently full of enthusiasm. Now he needs to think about
what he wants to do. Like many people of the project, he likes to think
in terms of implementation first, design second, and requirements last.
Perhaps he will honor us soon with a statement about what he would like
his feature to do, rather than just how he wants to implement it.

Firebird has a strong and flexible architecture with specific
responsibilities assigned to specific layers. There's often a
temptation to hack in a feature that "breaks the layering", but once
that is done, there is no longer an architecture. If you would like a
clear example of what happens when the laying is broken, you might try
to follow the anguish that another open source database is having with a
certain Pluggable Storage Architecture when there is no clear line
between what is server and what is storage handler. Firebird, more than
any other open source database project, has traditionally had a strong
sense of architecture. It has served the project well, and I hope it
continues in the future, even if people want a feature so bad that they
don't have time to think about it.

>
>> For
>> cross server joins, we'd also have to figure in the communication
>> time and latency and they have always been a moving target.
>>
>>
>
> That's why I proposed an abstract layer for the communication
> protocol. Also I think that the users know that they will have a
> latency there. And, from my POV, a program which will do many cross
> server calls on a slow connection perhaps has a design problem.
>

DSRI, OSRI, Interbase, and Firebird interfaces have always been defined
as APIs. The line protocol(s) exist to move API semantics over the
wire. As the system advances, this allows us to gracefully extend or
change the protocol to make it better without affecting the engine or
the clients. It also makes the Y-valve / dispatch module architecture
possible to support any number of engine and gateways on a server.

>

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376