| Subject | Re: [Firebird-Architect] Fetching from a non-cursor |
|---|---|
| Author | Jim Starkey |
| Post date | 2010-10-15T19:50:31Z |
On 10/15/2010 12:01 PM, Alex Peshkoff wrote:
another. 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.
--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376
> On 10/15/10 19:37, Jim Starkey wrote:OSRI is close to a dead horse, so I wouldn't worry about it one way or
>
>> 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?
another. 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.
--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376