Roman Rokytskyy wrote:

>>Don't store RDB$MODULE_NAME in RDB$EXTERNAL_ENGINE. Use the config
>>file.
>>
>>
>
>Ok, this is possible, though I do not like config files - embedded
>Vulcan is much less transparent in this regard than FB-embedded. With
>fbembed.dll I can access my databases without configs, in Vulcan that
>seems no longer to be possible - I have to configure providers. This
>is no longer a DBA-free engine from my POV.
>
>

Not quite true. Vulcan runs just fine with the default configuration
files, as does Firebird. Neither runs without a configuration file.

>
>
>>A C++ API is okay for Java and .NET that the project will distribute
>>the engines. But C++ programmers will need to use the same compiler
>>vendor/version or compile everything all the server.
>>The API is very small. Why not use C and distribute the C++ bridge
>>for external engine writers?
>>
>>
>
>I hope that Vlad can tell something more here - he was able to create
>a Delphi-based external procedure with this API.
>
>

In general, it isn't possible to fix C++ from different compilers. On
Solaris, for example, it isn't possible to link modules compiled by the
Sun Forte compiler and the gnu C++ compiler, and if I remember
correctly, neither can dynamically load libraries produced by the
other. In practice, any code that is going to be executed within the
engine must be compiled by the same compiler as the engine itself.

For engine extensions, I don't have any problem defining the interface
using C++ classes. If somebody wants to produce an external procedure
facility in Delphi, for example, it's not big deal to expect them to
code a tiny interface modules to handle the calling sequence coming in
and throwing the proper exceptions on the way out. I think there's
widespread agreement that the public APIs should be language neutral,
but I don't think this should be extended to facilities to run inside
the engine.

>
>
>>Could I consider that "virtual ExternalProcedure
>>getProcedure(ISC_STATUS* status, char* externalName) = 0;" mean
>>"virtual ExternalProcedure* getProcedure(ISC_STATUS* status, const
>>char* externalName) = 0;"? Note the ExternalProcedure*.
>>
>>
>
>Yes, you're right.
>
>

It would be nicer if you threw OSRIExceptions than messed around with
status vectors which seem oh, so, 20 years ago.

>
>
>>Why ExternalResource class exist? Why create a "close" method that
>>we know that will do "delete this"?
>>Use a virtual destructor.
>>
>>
>
>Not only "delete this". If I open a connection to another database
>(Oracle for example) and start pumping records into Firebird, I need
>some method to tell me "now you can stop and disconnect". I think this
>would be possible to achieve with virtual destructor too, but explicit
>method call seems to be logical here.
>
>

I think a mechanism for registering callbacks would be a better way to
handle this. Perhaps a two level handshake, one when the external
procedure facility is loaded to register call back hooks and another to
invoke a procedure. Or should it be per procedure?

>
>
>>I think ResultSet::getValue should be replaced with
>>ResultSet::getValues getting all the return values in one call.
>>
>>
>
>Sounds logical, but only if we agree that PARAMDSC or something
>similar is used to pass values in and out of the procedure. And from
>Jim's POV this can be answered only after answering the question about
>callbacks.
>
>

Jim rather thinks that the pre-existing ResultSet class might be a
pretty nice way to return a set of rows.

>So now I'm learning Vulcan and try to understand what advantage does
>the InternalConnection & Co. bring and why the struct with "ISC
>API"-like entry points plus two handles corresponding the public
>db_handle and tr_handle would not work or would be more inefficient
>than InternalConnection.
>
>Basically the structure with entry points is how it works now (at
>least in JNI layer that binds Fyracle and Java part), plus one more
>call to fetch current db and tr handles for the current context.
>
>
>

Roman, those handles are available. Accept it and get on with life.
The engine just doesn't have a clue as to what the Y-valve might have
invented for an external handle.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376