Hi Max,

> I must admit - it would be nice for us to be able to connect to a

Firebird

> Server and ask "what database files do you know about that I have
> permission to use?" without a registration overhead - using the existing
> aliases.conf entries.
>
> None of this would need to break anything existing - or add any extra
> steps. I'm not even asking for this as a feature - just saying it

would be

> a nice convenience (one less thing for us to do).

I agree it would be nice, providing it is disabled by default or there
is some method of whitelisting which aliases are 'advertised'.

> >
> > Unlike the other engines you mention, Firebird has no concept of
> > database registration.
>
> I don't think this is a necessary prerequisite - it's OK to be "just

what

> you know about" - rahter than "all databases".

With superserver, that may work, although as soon as the final
connection to a database is closed, the server 'forgets about' the
database. Classic server has a single process per connection, so it
isn't even aware of those databases.

I suspect that this alias resolution feature would be quite confusing
if it at certain times did not list some databases.

>
> > Aliases.conf is simply a method of abstracting the file system
> > location from the client connection string,
>
> Agreed - but it *can* be used by us, or as a table - but only for a
> particular database - it would be *nice*, though not necessary, for
> Firebird to provide access to the list - with security.
>

Sure, I posted earlier that we use it to determine which databases our
automatic offsite backup service picks up to avoid a double entry
there and the possibility that someone forgets to add a database to
the backup service and we lose data. It is definately a hack, but the
most reliable way I could think of to achieve the goal.

Perhaps what is needed is some more advanced version of aliases.conf
that is a database in its own right like aliases.fdb ;)

This could contain tables that hold all sorts of conditions about who
has access to what and when, and views and grants could be used to
police it. The downside would be the overhead of opening a database
rather than a simple text file.

Perhaps aliases could be done in XML to reduce this overhead yet still
provide the relational structures for requested information, but that
would be much harder to configure and easier to stuff up. Maybe it is
as simple as adding sections (similar to ini files) to the
aliases.conf for say [private] or [public] which defines what
subsequent some future API is allowed to return to the client.

It may be worthwhile to make an enhancement request.

Adam