> Me neither. When you talk about the Y-valve implementing SAPI, I'm
> confused.

> > Dispatcher won't execute the backup call, but as before, route it
> > to the appropriate provider which will be determined from the SPB.
>
> SPB parsing does not belong to the Y-valve, IMO.

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.

> > The provider on the client side won't be able to do any backup or
> > gfix things - those are tasks for the engine providers.
>
> I don't like it. Why functions of the utility become something that
> the engine should handle?

Let's check what is handled where:

- gbak: physical access to the database file is done in the engine,
however engine cannot write transportable backup files, it transfers
the content of the records, etc. to gbak utility which handles the
transportable backup file.

- gfix: operations that need physical access to the database file is
done in the engine anyway (e.g. validate), handling of limbo
transactions is just a convenience method.

- gstat: does physical access to the database file itself.

- gsec: as far as I know, user management is to be done in the engine
anyway.

- nbak: handled in the engine anyway.

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

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.

Moving transportable backup handling to the engine might sound
illogical, I will think whether it is ok or not.

But in general we get very straightforward structure - each request
goes down the pipe and each response goes up the pipe. No loops, etc.
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).

Roman