Den 2011-04-13 13:28 skrev Dmitry Yemanov såhär: > 13.04.2011 15:13, Alex Peshkoff wrote: >> >>> But, all things considered, I feel that the feature is too complicated >>> and has too many security implications to be worth it. If anything, I >>> might suggest that the alias config that's already present could be >>> augmented with a flag for each alias specifying if it should be >>> available for browsing or not (default = no). Those marked as available >>> for browsing could be accessible via an API function for that specific >>> purpose. >> >> This is quite reasonable option. > > Agreed. The question about location of the database list remains open, > however.
In what way? It is present in aliases.conf and I presume the server will either read this file on each attempt to connect to an alias, or cache the alias list somewhere in memory. Either way, the API function to retrieve browsing-marked aliases would fetch the list in exactly the same way as the connect function. I see no reason to do it any other way, unless you want to expose it in a system view (e.g. rdb$databases) in all databases as suggested by Jim a few minutes ago. But I'm against that - it makes it more complicated than it has to be. How is this feature related to upcoming support for schemas? I expect there's a potential overlap... Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@datadia.se Telefon: 08-761 06 55 Mobil: 0733-44 24 64 ------------------------------------------------------------------------------ Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
