At 12:29 AM 4/27/01 +1000, Mark O'Donohue wrote:

>
>
> And just checking, the Y-value switch stuff is basically in jrd/why.c, as
> I understand it
>

Correct. The term Y-valve, incidentally, is vaguely nautical. Around the
time I was designing the architecture the U.S. Goverment was promulgating
regulations mandating either sewage treatment plants or hold tanks on
small boats. The response of the boating world was device that would
direct, er, effluent either to a through-hull fitting (normal position)
to the holding tank (about to boarded by the Coast Guard position). The
device, naturally, became know as a Y-valve.

> What I am sugesting is implementing a similar interface to the Y-Value

within

> but using a java interface and different classes that
> Locally the jdbc client could hold a collection
>

Seems fine. Or better.

The Y-valve serves two functions: selection of a subsystem and
subsequent redirection of calls to the subsystem selected. It's
much the same idea of ODBC (ugh), just a little more clean, well
defined, and generally civilized.

The Java way of doing the same thing, of course, is to use a system of
interfaces, eliminating the intermediary as soon as a subsystem is
selected. This is superior in every respect to a mapping layer
(except, perhaps, having the blessing of Diane B.).

In the medium run I would like the see the original interface
architecture of Galaxy/Interbase/Firebird replaced with an
"interface" based system, which was the motivation of the
IscDbc component of the ODBC driver. Wean the installed
base away from the current interface to something more efficient,
extensible, and rigorous, and the software gods will smile
mightily.

>
> On a final note, one thing I can see c++ adding is providing a cleaner

way to

> implement the currenty why.c procedures with abstract base and concrete
> But thats a little down the track.
>

Yup. Much cleaner encapsulation. Should have used C++ in the first
place. The only sticking point was that it hadn't been invented yet.
Sorry.

> It would be interesting to see how isc4.gdb fits into the why structure
> particualrly for the relay mechanism you describe, and a final thought it
> also sounds possible to implement using a Y-Value server that maps from

alias

> names to file/url names.
>

It fits very badly indeed. Which should have been a tip off the
the designers that they had done something really dumb. Bad design
talks back; the trick is to listen.

Jim Starkey