Jim,

> 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.

It might be me ... but why not have a "connect to server" piece and then
use SQL to get your info from pseudo tables? Why XML?

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com