| Subject | Re: [Firebird-Architect] Re: Error Reporting in New API |
|---|---|
| Author | Jim Starkey |
| Post date | 2005-02-19T19:06:38Z |
Claudio Valderrama C. wrote:
Sometime back, I said that I though we needed a new primary
interface to replace the dreadfully inefficient DSQL interface. I
believe I said that the requirements for the new primary interface
should be:
1. Callable by most languages, i.e. 'extern "C"'
2. Supports the existing DSQL interface as a layer
3. Supports the existing IscDbc interface as a layer
4. Extensible, efficient, and readily adaptable to the remote
protocol.
Now, to answer your questions:
1. It isn't an internal interface because it's a user visible
external interface. By policy, all visible Firebird entrypoints
are considered architectural and guaranteed stable from version to
version. Furthermore, if it weren't an external interface, it
wouldn't be possible for either DSQL or IscDbc to be layered on it.
2. The interface exists so it can be called by code produced by
different languages and compilers. Vulcan, for example, supports
IscDbc, which is a C++ interface. Many of our platforms support
at least two C++ compilers, if not more. Windows, for example,
support g++, Intel, Microsoft, Borland, and god knows what else.
Each of these compilers needs a IscDbc wrapper, but the wrapper
itself must call a language neutral service, which is the new
API. Ditto Delphi and Java JNI. For object languages, the new
API will be much easier to use than the existing DSQL/XSQLDA
interface and much, much more efficient.
3. It is recommended for external use; that's why we're designing
it. In fact, it's only available for external use. The internal
SQL interface uses IscDbc.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>JTwo days ago I send you the following:
>
>Why not make it then strictly internal and you don't have to tackle the
>pseudo-object problem? The engine and the wrapper (the server) will be
>compiled with the same compiler unless you're mad, so there won't be any
>mismatch. If it's not recommended for external use, I don't understand why
>the hassle of the special error reporting feature that enchanted Dmitry
>Sibiryakov.
>
>
Sometime back, I said that I though we needed a new primary
interface to replace the dreadfully inefficient DSQL interface. I
believe I said that the requirements for the new primary interface
should be:
1. Callable by most languages, i.e. 'extern "C"'
2. Supports the existing DSQL interface as a layer
3. Supports the existing IscDbc interface as a layer
4. Extensible, efficient, and readily adaptable to the remote
protocol.
Now, to answer your questions:
1. It isn't an internal interface because it's a user visible
external interface. By policy, all visible Firebird entrypoints
are considered architectural and guaranteed stable from version to
version. Furthermore, if it weren't an external interface, it
wouldn't be possible for either DSQL or IscDbc to be layered on it.
2. The interface exists so it can be called by code produced by
different languages and compilers. Vulcan, for example, supports
IscDbc, which is a C++ interface. Many of our platforms support
at least two C++ compilers, if not more. Windows, for example,
support g++, Intel, Microsoft, Borland, and god knows what else.
Each of these compilers needs a IscDbc wrapper, but the wrapper
itself must call a language neutral service, which is the new
API. Ditto Delphi and Java JNI. For object languages, the new
API will be much easier to use than the existing DSQL/XSQLDA
interface and much, much more efficient.
3. It is recommended for external use; that's why we're designing
it. In fact, it's only available for external use. The internal
SQL interface uses IscDbc.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376