"Roman Rokytskyy" <rrokytskyy@...> wrote:

>
> I do not like it either, but somebody in old times decided to specify
> the database name in the SPB. Since all logic in dispatcher rotates
> around the database name, we have to peek into it anyway.

Not sure about that. isc_service_attach() call contains (or doesn't) host
name in its parameter. This is the only required info for the dispatcher to
call the subsystem (either locally or remotely). How the database name is
written doesn't matter at all, it will be analyzed when the particular
service will try to attach that database. So I see no need to parse SPB (in
my view of things).

> - gbak: physical access to the database file
> - gfix: operations that need physical access to the database file
> - gstat: does physical access to the database file itself

Why should the physical access matter here? Utilities are implemented to
share the code between services and standalong programs. If you integrate
GBAK into the engine, this code sharing will be lost. If you don't and keep
the service'd GBAK a layered code, then its integration into the engine
makes no sense (it will be yet another DSQL).

> So, everything that is missing in the engine now is writing the
> transportable backup files and move the gstat to the engine too.

Please don't be bound to the current utilities. Future ones can require no
particular database access but be complex enough to be undesirable within
the dispatcher. Or they may require access to a few databases
simultaneously.

> Moving gstat into the engine sounds logical anyway - we have no
> mechanism how to handle multiple gstat implementations for different
> ODS versions. Currently, it seems that gstat must be able to handle
> all possible ODS versions, which is what we wanted to avoid - one
> provider for one ODS.

Here I agree.

> But in general we get very straightforward structure - each request
> goes down the pipe and each response goes up the pipe. No loops, etc.

I still don't see loops as a problem. It worked since the very beginning and
it fits the architecture.

> Another advantage is that if all utility calls are already available
> in the engine, it is very easy to provide an SQL access to it, another
> "good thing" (tm).

Agreed about "good thing", but how would you suggest to implement
sp_get_active_db_count() call? SQL access can be easily implemented with the
services provider as well.


Dmitry