Subject | Re: [Firebird-Architect] RFC: External Engine API |
---|---|
Author | Geoff Worboys |
Post date | 2007-12-11T20:41:14Z |
Roman Rokytskyy wrote:
I do not understand how this is any different to C++/Java?
Either you build classes to carry the additional information
between calls (available in Delphi/Object-Pascal or C++), or
you use global variables (aka TLS), or you use additional
parameters. I am not aware of any secret features in C++ or
Java that offer any other solutions.
In IBO Jason has used a TLS slot to carry a default "session".
Each session is effectively a context - from which you can
extract the connection, transaction and statement instances,
including instances defined as the default connection etc.
However the TLS is only used to make the main interface simpler
(so that the average user does not need to know about the
default session), IBO does support the use of explicit session
instances passed to the constructor when you build connection
and other db object instances.
Some proxy object through which other calls are made could work
just as well with Delphi (IBO's session object is an example of
such a proxy - the choice of making that object accessible via
a TLS is not something the API need do).
IOW it seems to me that any solution you create for C++ or Java
_could_ be adapted for Delphi. I think the thing would be to
ask the library developers what they need/want - particularly
in the case of Delphi where (I assume most) development takes
place via an existing library rather than directly to the API.
--
Geoff Worboys
Telesis Computing
>>> So, from Java POV I'm ok with current API, but I see no[...]
>>> solution for Delphi without TLS.
>>
>> Why?
> Assuming that your question targets Delphi case, the answer
> is:
> Otherwise you have to require each procedure written in
> Delphi to take two additional parameters - current DB handle
> and current TR handle, and require Delphi code to pass them
> somehow into isc_XXX calls when callback mechanism should be
> used (btw, will IBO or FIB+ allow such things?).
I do not understand how this is any different to C++/Java?
Either you build classes to carry the additional information
between calls (available in Delphi/Object-Pascal or C++), or
you use global variables (aka TLS), or you use additional
parameters. I am not aware of any secret features in C++ or
Java that offer any other solutions.
In IBO Jason has used a TLS slot to carry a default "session".
Each session is effectively a context - from which you can
extract the connection, transaction and statement instances,
including instances defined as the default connection etc.
However the TLS is only used to make the main interface simpler
(so that the average user does not need to know about the
default session), IBO does support the use of explicit session
instances passed to the constructor when you build connection
and other db object instances.
> If, however, the question was "why it is acceptable for Java"[...]
> - well, I'd prefer Vlad's approach where I just have to use
> different DPB/TPB parameters. But I can also add some code to
> plugin and store handles in TLS in Java code later. Java
> requires some proxy between Firebird and JVM, so one can be
> relatively flexible there.
Some proxy object through which other calls are made could work
just as well with Delphi (IBO's session object is an example of
such a proxy - the choice of making that object accessible via
a TLS is not something the API need do).
IOW it seems to me that any solution you create for C++ or Java
_could_ be adapted for Delphi. I think the thing would be to
ask the library developers what they need/want - particularly
in the case of Delphi where (I assume most) development takes
place via an existing library rather than directly to the API.
--
Geoff Worboys
Telesis Computing