RE: [Firebird-devel] Services API Implementation

[Leyne, S. <Se...@br...>]

Ann,

> > I'd like to review, for a moment, the background of why the
utilities
> > are not built-in to the server itself.
>=20
> The utilities are not all of a piece.
>=20
> Gbak and ISQL are layered applications, like any user application.

I had not intended for ISQL to be included in my list of utilities, I
keep on forgetting about it, since I almost never use it -- remember I'm
one of Bill G's mindless disciples.

>  They
> can't be part of the engine, as Jim defines the engine, because they
> call in through the dispatch layer.

But GBak functionality could be.

Granted the GBak.exe would still remain but it could be a very
lightweight routine which simply opens a DB connection and then calls a
function inside the engine.


> Gstat is backward from that.  It's driven by a standard attachment and
> retrieval loop that reads the RDB$PAGES table to get the page numbers
of
> pointer pages.  It then does a physical file read to analyze the
pointer
> pages, data pages, index root pages, and indexes.

But these reading operations could be done by a function inside the
server, right?


> > Why can't the functions be built into the server itself?
> >
> Because in the Vulcan architecture you can't be both inside and
outside.

I'm not proposing that GBak, GFix or GStat be outside of the engine.


> > It would seem to me that having the functions built-in to the server
> > would make it easier to provide for SQL command interfaces for the
> > utilities.
>=20
> Not particularly as I understand it.

If the functions are built-in to the engine, then there is no need to
start a new process/thread, it would be like executing an SP.  As I
understand it, to implement GBak via SQL, the engine would need a way
send the backup instructions to GBak via the services API...


> > With the services built-in to the server, then the question of
having a
> > separate service process/thread would be mute, since the server
would
> > use the mode in which it was running (i.e. Linux -> processes or
> > pthreads, Win32 SuperServer -> threads, Win32 Classic -> processes).
>=20
> It would make the migration - particularly backward migration -
awkward
> if the backup and the server were all of a piece.

But that would be the responsibility of a tool, not of a native
function.  Think of how much fast a backup and restore would run if the
engine could write/read the backup file directly!


Sean