On 04/13/11 12:02, Geoff Worboys wrote:
Why: developers/end users can more easily choose and connect
to a database on a Firebird server, even point and click.
Point and click should be implemented by client, not by server.
I cannot speak for the original author, but it seems to me the
one
13.04.2011 11:45, Geoff Worboys wrote:
More seriously. Yes I know there are important security
considerations BUT I thought perhaps people were overlooking
what I see as the biggest potential advantage of the request.
Just because it is a risk does not take away the potential
for advantage.
On 13-4-2011 12:04, Dimitry Sibiryakov wrote:
13.04.2011 11:45, Geoff Worboys wrote:
More seriously. Yes I know there are important security
considerations BUT I thought perhaps people were overlooking
what I see as the biggest potential advantage of the request.
Just because it is a risk
Den 2011-04-13 12:34 skrev Vlad Khorsun såhär:
In this way, you lose dynamic registration, and have the administrator
manage the list of databases shown in RDB$DATABASES.
In what database ?
This obvious question has two possible answers as I see it:
1. All. Any database you're connected
On 04/13/11 14:55, Kjell Rilbe 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
12.04.2011 2:09, Adriano dos Santos Fernandes wrote:
I suggest we fix namespace usages in an incremental manner. How?
[skip]
This way subsystems are children of Firebird namespace and don't require
Firebird:: everywhere. We also avoid using namespace Firebird in
implementation files.
It
On 13-4-2011 13:13, Alex Peshkoff wrote:
On 04/13/11 14:55, Kjell Rilbe 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
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
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
Dimitry Sibiryakov wrote:
13.04.2011 11:45, Geoff Worboys wrote:
More seriously. Yes I know there are important security
considerations BUT I thought perhaps people were overlooking
what I see as the biggest potential advantage of the request.
Just because it is a risk does not take away the
How is this feature related to upcoming support for schemas?
This feature have nothing common with schema support.
Regards,
Vlad
PS Access to the aliases list via new service seems enough as for me.
--
Forrester
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.
I meant the virtual location,
Den 2011-04-13 12:55 skrev Kjell Rilbe såhär:
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
On 04/13/11 16:02, Kjell Rilbe wrote:
Den 2011-04-13 12:55 skrev Kjell Rilbe såhär:
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
Hi,
I've noticed that the win32 version of fbclient (v2.5) is built using
the synchronous exception model (i.e. using the /EHsc- option). This
means that destructors for RAII objects such as the RefMutexGuard will
not be called when a non C++ exception occurs (e.g. an Access
Violation).
15 matches
Mail list logo
