At 09:32 AM 5/1/00 -0400, Matt Larsen wrote:

>
> If we changed back to this mindset and ALWAYS allowed
>backward compatibility, would it not be a fairly easily to extend gbak to
>read a "legacy" database and write a new database using current ODS to a new
>file(s) (as Markus or Bill mentioned doing with pipes)? If I were
>considering creating a widely distributed application using Interbase as the
>database, I would not be comfortable with the fact that anytime a
>significant new version comes out I would have to force my customers to do a
>backup and restore.

I think the architecture of GBAK needs a little explanation. GBAK
is a properly layered, user level program that uses the published
API to back up and re-create database files. It doesn't know
diddly squat about ODS. It does through the Y-valve just like
any other program to access or create a database. Since, by
default, the Y-valve channels ISC_CREATE_DATABASE calls to the
most recent engine, GBAK automatically spans versions.

To increase performance by eliminating interprocess communication,
in V6 GBAK is packaged in the engine. And, yes, this is a temptation
to break the layering, but as far as I know, this hasn't happened
yet. There are some switches to tell the engine that the client
is gbak and to alter garbage collection accordingly, but, in theory,
at least, this is part of the API even if inadvertantly (ahem)
unpublished. When the source is openned, it will be there for
all to see.

The original philosophy of both the DEC Rdb products and Interbase
is that the entire API is exposed, there are no back doors, no
hidden switches. This is the ONLY way that a well architected
database system can evolve. Breaking the rule even once, in
the most innocent, well meaning way, leads inevitably to the
type of moronic hackery present in Java 1.2.

The primary vehicle to ensure clean architectures is this list.

Jim Starkey