Subject Re: [Firebird-Architect] Strategic Replacement for Services API
Author Arno Brinkman
Hi Jim,

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

Sounds almost like SOAP ( ;)

The idea about an administration service communication with XML sounds good to me, because it's
indeed a flexible way to handle things.
If this service also will able to return the log-file i hope we'll also support compressed-XML.

If there will be a thirth party implementing a web-service as GUI frontend then it's accessible for
every OS with a web-browser :-)

Arno Brinkman

General database developer support:

Firebird open source database (based on IB-OE) with many SQL-99 features:

Support list for Interbase and Firebird users:

Nederlandse firebird nieuwsgroep: