Subject Re: [IB-Architect] RE: Classic vs. superserver (long, very very long)
On 15 Oct 2002 at 16:19, Ann W. Harrison wrote:

> At 02:05 PM 10/15/2002 -0400, pschmidt@... wrote:
> >We (royal we here), would need to rewrite the SQL compiler, not sure how much
> >work that would be,
> Not a huge amount. In fact, there's only one module in DSQL
> that would need significant changes and that is gen.c - the blr
> generator. The intermediate structures are fine and can easily
> hold the semantic information necessary to generate the first
> stage of the execution tree.

Okay, I wasn't sure what was there, and how much of it needed to be changed,
mostly not sure what people have done to it, since Jim wrote it, it wouldn't take
much for someone at a certain software company to take a nice simple, well
working mechanism and totally FUBAR it.

> >I haven't seen the code, and downloading the source is a major
> >drag at 48K.
> >It's an issue of, might as well as, it's all ripped apart anyway, and
> >changing some of
> >the data structures might lower the PITA factor, rather then doing
> >something in a
> >goofy manner, clean up the data structure and do it the way it should be done.
> Err.... maybe not the right choice of words. The data structures are
> pretty much OK - we're just going through an unnecessary intermediate
> step. For those of you who haven't been intimate with InterBase internals
> since infancy, here's the history of DSQL. For the seriously uninitiate,
> DSQL is dynamic sequel (that's another discussion), which allows queries
> to be generated on the fly. The assumption when InterBase and its
> predecessors were designed was that all dynamic code generation would
> be done by high level tools.

I figured as much, after all it's logically Monday around here (Canada has
Thanskgiving the 2nd Monday of October, after all parts of this country will be in the
deep freeze in another month).

> 1984. Don't have it, don't want it. That's what BLR is good for. If
> you want dynamic queries, write a blr generator.
> 1985. Somebody pays us to implement DSQL. It runs on the client and
> generates BLR and low-level API calls.
> 1987. Somebody notices that client/server applications really suffer
> with DSQL because the client needs lots of metadata to support
> BLR generation, so a simple query turns into a full-fledged
> conversation between client and server.
> 1990. DSQL moves to the server side, but as a separate library (I think)
> still generating BLR and low-level API calls.
> Since then DSQL has been nudging its nose into the tent, but the relationship
> has never been formalized.

Maybe its time it was formalized, not saying that BLR doesn't have it's advantages,
but most people who work with systems like Firebird, have never used it, and some
probably are wondering what it is (me included).