> 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.

> Don't initialize RDB$EXTERNAL_ENGINE at CREATE DATABASE. It's
> problematic for backup and restore.
> Create a DDL statement: CREATE EXTERNAL ENGINE ...

Good suggestion.

> 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.

> 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.

> 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 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.

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