Roman Rokytskyy wrote:

>>>So, the question is whether we define a new module for "C"
>>>language that would resolve the external name
>>>"ib_util:some_procedure" on Windows into "ib_util.dll" and
>>>"some_procedure" entry point?
>>>
>>>
>>Yes, I think so.
>>
>>
>
>Ok, then if no other comments come, let's assume that's the solution.
>
>
>

Let's not be too hasty here. Logically, two text strings are required.
The first is an identifier for an external procedure facility. The
configuration file, presumably, will map a facility name into a physical
library. The second is the internal procedure name which is necessarily
facility specific. For a Java external procedure, this would probably
be of the form "<class>.<method>".

The key elements that need to be defined are the look up mechanism and
the generic external facility interface. The mapping is trivial with
Vulcan configuration files. The call interface is the critical item,
and will require some actual knowledge of how the Firebird engine
interacts with other Firebird components, a knowledge that has been
sorely lacking in this discussion so far.

I suggest we temporarily suspend this discussion to allow Roman to learn
something about the engine, handles, and software layering. If, after
he has figure out how Firebird actually works, he still wants to
re-architect the system, we can resume the discussion in a more
intelligent vein. In the meantime, I will put together a post reviewing
the Firebird architecture. Perhaps once people understand that the
component called "the server" is a thin layer sitting between the wire
and client API without the slightest clue of database semantics, they
will better able to describe their rare and keen insights into what we
have been doing so dreadfully wrong for the last 20 years.


[Non-text portions of this message have been removed]