On 07/22/14 04:10, Jim Starkey wrote:
> I do have some questions:
>
> 1. Does it reflect a plan to introduce schemas, i.e. two level name spaces.
Yes. It's designed to be expandable to as many new field properties as
will be needed in the future.
> It not, it should be rejected out of hand. The rest of the database world
> accepted that name space control as obligator a decade and a half ago.
> Changing the interface without make it better, i.e. future proof, makes no
> sense.
>
> 2. Does the new interface get rid of fixed interface structures? I
> introduced them 30 years ago for compatibility with DB2 as the only published
> dynamic SQL interface. This was a terrible mistake. The SQLDA, friends, and
> relations were, are, and always will be disasters. Static data structures
> become obsolete in a blink of an eye. The history of Firebird is sufficient
> living proof. The API has been changed many times without making it better.
> Gentlemen, it is time to learn from past failures.
Reviewing API from this POV I've found 2 plain structures.
One is
struct FbCryptKey
{
const char* type; // If NULL type is auth plugin name
const void* encryptKey;
const void* decryptKey; // May be NULL for symmetric keys
unsigned int encryptLength;
unsigned int decryptLength; // Ignored when decryptKey is NULL
};
it's used to pass keys from authentication plugin (like SRP) to wire
crypt plugin (like RC4).
Next is
struct DtcStart
{
IAttachment* attachment;
const unsigned char* tpb;
unsigned int tpbLength;
};
which usage appears obvious - start distributed transaction over >1
attachment.
It's very easy to change them to interfaces, but as a result of
discussion I had to agree that there are no ways for this structures to
be changed. As for me I anyway prefer to see them in interface form, but
had to agree with other people.
What do you think - should that 2 structures become interfaces?
>
> 3. A good interface has strict differentiation from structure and semantics.
> A bad interface requires incompatible tweaking with the semantics are
> extended.
Attention was paid to make interfaces independent from both structure
and semantics.
But how can I surely say "yes, it's ok" provided we still did not have
serious changes after it's design?
> 4. Do all interface objects have methods to interogate the object (not API!!)
> version?
Yes. All interfaces are derived from IVersioned. It has function
getVersion(). Returned value (i.e. interface version) is equal to the
number of virtual functions in the interface.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
