Helen Borrie wrote:

> At 09:56 AM 25/02/2009, Jim Starkey wrote:
>
>> A brief review for the uninitiated. Two rules:
>>
>> 1. An engine cannot open a database with a different ODS major
>> version number
>>
>
> ...with a higher ODS major version number than the highest one it supports
>

Wrong, Helen, wrong. If an engine can support two versions, then a
change to the minor ODS version is appropriate. A major version, by
definition, is one that a single engine version can't hack.

>
>> 2. An engine can open a database with a minor version number <= the
>> engine's minor version
>>
>> An ODS major version number change is major intergalactic extinction
>> event and is extraordinarily rare.
>>
>
> Ah, how simple it was, so long ago, when galaxies were believed to be finite and immutable.
>

It still is simple if you take the time to understand it.

>
>> An ODS minor version number change is small potatoes and has very few,
>> if any ripples.
>>
>
> That's the intention of a minor version number change.
>
>
>> Change the interpretation of Hdr::pageSize (or whatever it's called in
>> Firebird) is no problem if the minor version number is bumped. Old
>> versions of the engine won't touch it with a ten foot (3M) pole, but new
>> versions with use the actual minor version number of a database to
>> interpret the field.
>>
>> Sean's hack is really a hack at all, but a perfectly reasonable
>> redefinition of a field, one of those things that happens when we live
>> long enough to get smarter.
>>
>
> Notwithstanding all of the drivers, tools and existing embedded codebases are taught what it means, in time to interpret it properly when confronted with it. Anything with this kind of impact can scarcely be regarded as "small potatoes...having very few, if any, ripples"...which brings us back to an ODS change that is more-than-minor...as any who made the step from 2.0 to 2.1 will testify.
>
>

ODS changes, major or minor, shouldn't be visible to the clients. They
are an internal engine issues, no more.

And, might I point out, the provider architecture that you so gallantly
trashed had provision to support an arbitrary set of engines supporting
different major ODS versions as well as gateways other other products.
The original point of the OSRI architecture (look up architecture,
Helen, it's an interesting concept) is that the Y-valve would poll
engines looking for one that could handle a particular attachment
string. This went far beyond major and minor ODS versions, encompassing
competing products, gateways, legacy engines, etc.

Until the architecture got trashed, an Interbase/Firebird client could
access Firebird, Interbase, Rdb/ELN, Rdb/VMS, and on a good day, Oracle,
all without any change to the client.

So, Helen, you have already made your contribution to destroying a
powerful, working, and extensible architecture. There is a better way,
but it requires an open mind. Let's try to go there sometime.