--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@...>
wrote:

>
> 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.
>

No, I didn't suggest this. But as far as I analyse the problem I see
two (rather) distinct cases. If you pay attention at my first
message, you'll see that, in fact, I proposed more or less the same
ideea that you did. But now I think that is a rather different
situation when we have the DB files stored locally, so, we can simply
(I think) do our job (in a superserver architecture even easier, I
think...), and the other case is the one which both of us tried to
cover by using a server-to-server communication engine (which is
_very_ important to be a very good one because, IMHO, this
communication layer can be used in the future to do other things like
clustering). In fact, the Firebird itself has a different approach
(internally of course) when it deals with a local fdb (through XNet),
and when deals with a remote one. It doesn't connect through TCP/IP
at 127.0.0.1 (and this is the way it should be, IMHO). I proposed
that because, in my opinion, the most common case is when a DBA has
all the DB files locally, so, again, _in_my_opinion_ (which is _very_
doubtfull) I think that this solves much more than 15%. An this can
be done in FB V3. The best approach which is more complex I see it
after V3. But I think that its pointless to argue about percents, I
think that the best thing is to put a poll on firebirdnews.org about
this thing. Something like:

"Dear users, we want to implement cross-database joins. What do you
choose:
1. I preffer rather to wait for a full blown implementation both for
local and remote FDB.
2. I need now a simple implementation for local FDBs only but I'm
interested in a future global approach.
3. I need now a simple implementation for local FDBs only (I'm NOT
interested in extending this feature, move your resources in other
areas).
4. I'm not interested in cross-database joins.
5. (...other choices...)

What do you say?

...because I think that the users must have the final word. Anyway,
perhaps, is better to know that, generally, I'm on your side but I
see that are rather few coders on FB tree and to attract more
programmers we need to have a better product, to have a better
product we need more programmers aso...

> 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.

Agree. But I thought that Adriano would use a kind of loopback ie.
attach as another client to another thread of a superserver
architecture let the other 'server' (ie. thread) to do its job, and
fetch the data back, but moving it through a pointer, if possible, or
if not, through a memory move. The very-poor-man implementation of
this would use a scratch/external file to move the data between
processes/threads.

> 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.
> >
>

Agree. And I preffer this solution. But who's gonna do it?

My 2c,

m. th.

>
> --
>
> Jim Starkey
> Netfrastructure, Inc.
> 978 526-1376
>