Roman Rokytskyy wrote:

>
>
> a) Is ServicesAPI part of the Firebird API that server implements or not?

Yes, the server implements it, but the local engine does not. It's a
separate provider under the dispatch code.

>
> b) Are you going to change the API itself by introducing new calls?

No.

>
> So far I do not see any problem with the current solution as far as
> application programmer is concerned:

There are two problems. First is that the Vulcan engine provider does
not include the services API. That may seem arbitrary and capricious,
but the services code is designed to be layered on the engine, not
embedded in it. The current implementation of the services API mixes
layered code with internal engine calls. That's why it's not currently
in Vulcan.

The suggestion is to make a separate provider that implements the
services API. That restores the layering and gives us a chance to
reduce the amount of conditional code in the utilities.

>
> - if server is accessed over TCP, there is an API (part of wire
> protocol), both JayBird and .Net provider have native implementation
> of this part;

That's fine. That will still work.

>
> - (my guess) same API exists when IPC is used;

Yup, and still works.

>
> - embedded part calls the entry points in the embedded engine, this is
> also an API.

That will also work. All three of those - the servers and the embedded
application are above the dispatch code and will see the API as it now
exists.

>
> So, do I understand it correctly, that the discussion is about
> internal implementation of the gbak, gsec & co. utilities, whether the
> implementation should use that API or some internal tricks?

More or less. Right now they're typically one piece of code with
conditional bits for creating a standalone application or something that
can be linked with superserver.

> If this is so, isn't it something that should be solved during Vulcan
> development or merge?

Right now Vulcan doesn't support the services API. If we're going to
let people use it, we need to do something about that.

>
> And if this is so, why nobody cared to implement the separate client
> libraries for TCP and IPC calls that do only what they have to do -
> send data over the communication channel to the server, basically do
> what JayBird and .Net provider already do?

None of this will make any difference to Jaybird or .Net

Regards,


Ann