So lets see if I have this right...

You propose that Firebird should implement an administration
server - basically an object or process that represents the
server itself rather than just a particular database engine.
However many database engines may be loadable, there would
presumably be only one administration server.

I am not much fussed on the implementation detail at this
point (your XML suggestion has potential coincidence with a
posting made recently about BEEP http://beepcore.org/).
However it does strike me that the administration server
could be just another database engine - with its one admin
database - as this would allow much existing architecture to
be reused directly.


I am interested in how we could use this capability to finally
get some higher level administration capabilities.

The ability to extract lists of available databases (ignoring
the solvable security issues) would be a useful feature,
although having already solved this one externally it is not
a burning issue for me.

What I would like to see is the ability to manage server
security, ie: what users are permitted to create databases in
what locations. Taking this further it could even be used to
control what databases are even visible to various users.

As I mentioned some months ago, I would prefer that server
configuration details that should be controlled - or at least
restrictable - at the server level and not at the database
level. For example it is the manager of the actual server
hardware that should be able to control the memory that a
particular database instance is permitted to use - it should
not be up to a database attribute. There are similar (ableit
more complicated) issues in regard to secondary and show file
locations.

Some of these long outstanding issues would allow DoS attacks
by anyone that has gained access to ANY FB user/password. This
vulnerability makes some solutions awkward. For example there
are times when a developer wants to access a specific database
without bothering the user with user/password details. This
can be solved by hardcoding such details (or storing them in
a config file or whatever). But such insecure password storage
potentially leaves the entire server open to attack.

The actual control aspect of some of these issues could be
solved by the use of your new configuration files (if I have
understood them), but we need an administration server to allow
remote maintenance (after appropriate authorisation) of that
configuration.


So yes, I would really like such a feature as an administration
server, but before an architecture is selected I think it would
be wiser to discuss what we actually want such a beast to be
able to do. For example; are the concerns I have expressed
above legitimate and could they be solved by an admin server.

--
Geoff Worboys
Telesis Computing