On Jul 27, 2005, at 3:37 PM, Jim Starkey wrote:

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

seems more or less reasonable as long as you stay far away from the web
service "standards"

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

Are you thinking of providing a schema for the command and response
structures? How will the extensibility elements fit into the schema?
IMO schemas are pretty much necessary but the extensibiltiy stuff gets
hairy quickly.

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

Whatcha got against doing it once in java???? An eclipse plugin would
also see wide use :-)

thanks
david jencks

>
> 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
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>