Roman Rokytskyy wrote:

>>The issues can't be separated -- what is passed to an external
>>procedure facility must be sufficient for a procedure to do it's work,
>>
>>
>
>Now I think I understand our problem here - the key phrase is "what is
>passed".
>
>

Exactly!

>It is correct, that you, Jim, expect the engine to pass the callbacks
>(whatever they are - isc_XXX, jrd8_XXX or InternalConnection instance)
>into the open(...) method of the external procedure?
>
>

I don't think it is feasible to export any engine entrypoints, per se,
since all are internal interfaces subject to change without notice.
This is why I created InternalConnection, Attachment::getUserConnection,
and Database::getSystemConnection().

>If that is your expectation, then it is different to what we were
>thinking about - we were thinking about getting the callbacks from the
>environment when and if needed (think of TLV, for example). In this
>case we can concentrate on the parameter passing first without
>discussing the callbacks. If that is wrong from your POV, please
>explain why.
>
>
>
>
>

My main concern is the relationship between and external procedure
facility and the engine. The external procedure facility is loadable,
so it can't access and engine entrypoints (a provider exports a single
symbol) or engine data structures. On the other hand, it must operate
as part of the host request's transaction and honor savepoints, etc.
The big questions are what services must be exported to external
procedures and what sort of hook registration mechanism might be required.

But seriously, we can't possibly discuss parameter passing and APIs
without know what semantics must attach to them.

TLV? What's TLV? Looks like another TLA to me. I can handle POV, though.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376