In a post last week, Geoff Worboys mentioned that something he needed
was a mechanism to determine the names of available databases. Putting
aside the solveable issue of security, this struck me as a reasonable
request, perhaps problematic, but something we might want to support.
The services API would be the logical place for such service, but given
the rather limited scope of the existing services API, it is hardly up
to the task of reporting a list of database let alone a list of
databases each with an open ended collection of attributes.

Rather than pushing the services API, I think it's time to talk about a
strategic replacement. While we want to maintain the services API, I
think it's a waste of resources to extend it.

As a strategic alternative, I suggest we consider a standalone
administration server to take over the services API functions as well as
new extensions. An architecture I've used before is a GUI frontend
communicating with a backend administration server exchanging XML
trees. The interface to the administration backend is pure XML, so any
number of front ends -- command, gui, or API -- are possible. In every
case, the front end establishes a socket to the administration server,
establishes its credentials (login, site password, or other suitable
authentication), the sends XML structured commands. The adminstation
server parses and validates the XML, then dispatches to a named
service. The result of a request (or reasons for failure) would be send
back to the front as XML.

I'd be incline to structure the administration server so actual services
are loadable modules for extensibility, with a local (probably XML)
configuration file, with the requests passed as parsed XML. This would
allow for third party administration tools within an established framework.

In addition to the current services API, we would also want facitities
to return information about known databases and database attributes
(gotta throw a bone to Geoff), modify Firebird configuration files,
invoke other backup tools, restart servers, etc.

The split between front and back end using XML as request protocol is a
very easy, robust, and extensible technology -- basically anything can
be passed either direction. If I were doing it, I'd create a Window's
GUI in C++ for the front end and C++ for the administration server. I
have a lifetime ambition never to do another Unix GUI, so if we go that
path, it's either Wine or somebody else's front end.

There are other advantages of an administration server outside the
database server process, particularly when execute extensions. If the
extension crashes, the worst case is that the front loses it's
connection to the backend -- nobody is gets clobbered.

Any thoughts?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376