Subject | Re: [IB-Architect] IB Aliasing system |
---|---|
Author | Jim Starkey |
Post date | 2000-11-30T16:40:59Z |
At 01:18 PM 11/30/00 -0300, Marcelo Lopez Ruiz wrote:
the prosaically named Y-valve (why.c) and an open ended set of isomorphic
subsystems (engines, transports, or gateways). The basic idea was this:
On the attach_database call the Y-valves blindly polls each subsystem
to see if they can resolve the attach string. If the system returns
success, the Y-valve encapsulates the handle and returns success;
otherwise it goes on to the next subsystem. Thereafter, the Y-valve
is merely dispatches calls back to the winner (and runs two phase
commits). This architecture allows a great amount of configuration
freedom -- transparent access to multiple versions of the engine
(or none on client-only systems), gateways to other RDBMSes, various
transport schemes. It also allowed double indirection for
attachments to cross network barriers such as tcp/DECnet/Apollo
ring.
Borland, of course, has substantially trashed the implementation,
though not the concept, of the Y-valve by breaking the layering.
A motivated engineer with a nose for software rot could set it
right without a great deal of trouble (hint hint, nudge nudge).
Great thought should be given to where the alias handling should
take place. If the intention that an alias should allow redirection
to another system, then alias handling belongs in Y-valve. If
the scope of aliases is restricted to local database file names,
the handling belongs in JRD (the engine).
In Netfrastructure, without the need (or ability) to double
indirect, I use an alias mechanism to mask local database
file names. It works well, but I find the need to register
a database, er, content store, before I can get it somewhat
of a pain in a development environment but just fine in production.
Maybe I'll retrofit an explicit file name in place of a database
name. smop.
On a different topic, it has been pointed out that "Jim Starkey"
is exempt from the list anti-flaming rules. Does this mean that
I can flame or that only I can be flamed? An inquiring mind
wants to know?
Jim Starkey
>The original Interbase (sic) architecture was a strict layering of
>A big part of my idea was being able to implement this scheme without
>modifying the engine. This lies totally outside the realm of InterBase -
>it's simply a tad overengineered way of not hardcoding connection strings.
>
the prosaically named Y-valve (why.c) and an open ended set of isomorphic
subsystems (engines, transports, or gateways). The basic idea was this:
On the attach_database call the Y-valves blindly polls each subsystem
to see if they can resolve the attach string. If the system returns
success, the Y-valve encapsulates the handle and returns success;
otherwise it goes on to the next subsystem. Thereafter, the Y-valve
is merely dispatches calls back to the winner (and runs two phase
commits). This architecture allows a great amount of configuration
freedom -- transparent access to multiple versions of the engine
(or none on client-only systems), gateways to other RDBMSes, various
transport schemes. It also allowed double indirection for
attachments to cross network barriers such as tcp/DECnet/Apollo
ring.
Borland, of course, has substantially trashed the implementation,
though not the concept, of the Y-valve by breaking the layering.
A motivated engineer with a nose for software rot could set it
right without a great deal of trouble (hint hint, nudge nudge).
Great thought should be given to where the alias handling should
take place. If the intention that an alias should allow redirection
to another system, then alias handling belongs in Y-valve. If
the scope of aliases is restricted to local database file names,
the handling belongs in JRD (the engine).
In Netfrastructure, without the need (or ability) to double
indirect, I use an alias mechanism to mask local database
file names. It works well, but I find the need to register
a database, er, content store, before I can get it somewhat
of a pain in a development environment but just fine in production.
Maybe I'll retrofit an explicit file name in place of a database
name. smop.
On a different topic, it has been pointed out that "Jim Starkey"
is exempt from the list anti-flaming rules. Does this mean that
I can flame or that only I can be flamed? An inquiring mind
wants to know?
Jim Starkey