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 (http://www.w3schools.com/soap/default.asp) ;)

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 :-)

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database developer support:
http://www.databasedevelopmentforum.com

Firebird open source database (based on IB-OE) with many SQL-99 features:
http://www.firebirdsql.org
http://www.firebirdsql.info

Support list for Interbase and Firebird users:
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep:
news://newsgroups.firebirdsql.info