On 10/15/10 23:50, Jim Starkey wrote:

> On 10/15/2010 12:01 PM, Alex Peshkoff wrote:
>> On 10/15/10 19:37, Jim Starkey wrote:
>>
>>> May I recommend that the next time somebody wants to make an
>>> incompatible change to DSQL, don't. Instead, create a new API that can
>>> be extended in an upwards compatible manner. The base DSRI / OSRI /
>>> GDS/ ISC/ Firebird API has worked out quite well, as have SQL-based
>>> APIs. There are many to pick from or to use as models. Put the ugly
>>> DB2 API out to pasture as a legacy interface and find or build something
>>> you can live with.
>> Jim, I've also had such idea, but in this case provider's behavior must
>> depend upon from what interface was it called.
>> It's doable, but is it OK from OSRI point of view?
> OSRI is close to a dead horse, so I wouldn't worry about it one way or
> another.

Sorry, may be I've used not correct word - I've meant provider's
achitecture, when single yValve can call various providers. Imagine that
future version of firebird, which supports provider's achitecture (does
not matter what particular API is used in it) is extended with some gate
to old GDS/ISC API. The question is - can behavior of provider depend
upon, was yValve called using that old-API gate or not?

> Start with the requirements -- who is going to use the API and
> how. The thinking that went into DSRI/OSRI was that the two major
> clients would be pre-processors and 4GLs. At this point in time, the
> major clients are application developers; pre-processors and 4GLs have
> almost disappeared from the landscape. The next question is what
> language do you need to support. The first DEC pre-processors where for
> Pascal, Basic, Cobol, and Fortran. None of these are particularly
> interesting any more. If you are willing to constrain usage to OO
> languages, then you can go with an OO interface. Otherwise, a more
> complicated API may be necessary.
>
> A lot of thought needs to be given to minimizing round trips and
> avoiding slopping around unnecessary metadata. Obviously, there's a
> tradeoff there.
>
> Personally, I incline towards standardized APIs if at all possible. For
> both Netfrastructure and NimbusDB I went with JDBC. I don't
> particularly care about non-OO languages, but other people are likely to
> have strong opinions to the contrary.
>
> The main point, however, is never, ever build a static structure into an
> API. The structure will always need extending for some unanticipated
> reason, and a change will break upwards compatibility.
>

I've used COM-like objects in firebird3.