Subject | Re: [Firebird-Architect] Services API |
---|---|
Author | Nando Dessena |
Post date | 2005-04-22T08:45:36Z |
Jim,
J> class that can be extended compatibily.
well, that was (at least) the intention of the designers of the
services API, I think. Each service is exposed as a pseudo-object API
and is encapsulated into a class in the client environment. Not sure
how much nice and how much clean, though.
If I understand you correctly, the solution you are proposing
pairs with your idea of an object based API (please correct me if I'm
wrong) which was discussed at length in this list, and about which I
am waiting to see some specs to make my mind about what the benefits
would be for a Delphi client.
Ciao
--
Nando Dessena
http://www.flamerobin.org
>>>>J> I'm not sure we want to go through the pain and suffering of hammeringJ> I think the best solution to wrap each utility core into a nice clean
>>>>J> out utility APIs that we can live with in perpetuity, so I suggest that
>>>>J> the APIs beconsidered ad hoc and subject to change without notice.
>>>>Fair enough. But will changes to it be documented?
J> class that can be extended compatibily.
well, that was (at least) the intention of the designers of the
services API, I think. Each service is exposed as a pseudo-object API
and is encapsulated into a class in the client environment. Not sure
how much nice and how much clean, though.
If I understand you correctly, the solution you are proposing
pairs with your idea of an object based API (please correct me if I'm
wrong) which was discussed at length in this list, and about which I
am waiting to see some specs to make my mind about what the benefits
would be for a Delphi client.
Ciao
--
Nando Dessena
http://www.flamerobin.org