On 04/12/11 19:27, Adriano dos Santos Fernandes wrote:
> On 12-04-2011 04:13, Alex Peshkoff wrote:
>> Adriano, I do not wnat nitpicking. Moreover, I agree that my commit was
>> (not to say more) bad. But your initial solution with non-POD objects
>> in API was also bad. I have not understood - do
13.04.2011 10:31, Jim wrote:
>
> - Ease of use for end users:
> -- Their applications can be modified to provide point and click GUI
> connection options: avoids typos, extra documentation, looking up
> aliases, and bothering IT staff.
Even if this proposal would ever be implemented, I'd suppose i
On 04/13/11 10:31, Jim wrote:
I will comment this mainly from security POV.
> 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.
> Cons:
> - Increased code com
>> 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 BIG advantage of offering aliases.conf
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
Alex Peshkoff wrote:
> Yes, and this is like all secure daemons work. Have you ever
> seen something like DNS server, which changes it's configuration
> itself? Or HTTP server, doing such tricks? File sharing daemon
> like samba can change own configuration if it's conf file is
> shared, but for me
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 advanta
AV in engine if isc_que_events queued 0 events
--
Key: CORE-3440
URL: http://tracker.firebirdsql.org/browse/CORE-3440
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects
On 13-4-2011 9:39, Alex Peshkoff wrote:
> On 04/13/11 10:31, Jim wrote:
>
> I will comment this mainly from security POV.
Ok, thanks.
>
>> 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 imp
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
> In this way, you lose dynamic registration, and have the administrator
> manage the list of databases shown in RDB$DATABASES.
In what database ?
Regards,
Vlad
--
Forrester Wave Report - Recovery time is now measure
> > In this way, you lose dynamic registration, and have the administrator
> > manage the list of databases shown in RDB$DATABASES.
>
> In what database ?
I'd suggest: aliases.fdb ;)
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http:/
On 13-4-2011 12:34, Vlad Khorsun wrote:
>> In this way, you lose dynamic registration, and have the administrator
>> manage the list of databases shown in RDB$DATABASES.
>
> In what database ?
>
> Regards,
> Vlad
Hi Vlad,
You mean in what database does RDB$DATABASES reside? You got the weak
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 conn
13.04.2011 12:33, Jim wrote:
> I do understand the objections, but I think this feature makes Firebird
> a bit more newbie-friendly and increases the "you don't have to think
> about it, it just works" factor.
Currently Firebird already has low entry threshold and it compromised
Firebird's
re
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 spe
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 fi
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
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 pr
On 04/13/11 15:28, Dmitry Yemanov wrote:
> 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 coul
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
> 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
13.04.2011 15:34, Kjell Rilbe wrote:
>> 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 somewher
13.04.2011 13:39, Alex Peshkoff wrote:
>> Agreed. The question about location of the database list remains open,
>> however.
>>
>
> Services API?
MON$DATABASES?..
--
SY, SD.
--
Forrester Wave Report - Recovery tim
13.04.2011 15:39, Alex Peshkoff wrote:
> Services API?
This would get my vote. I'm just unsure how much happy users are going
to be with this solution.
Dmitry
--
Forrester Wave Report - Recovery time is now measured i
>>> 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 "vi
Den 2011-04-13 13:48 skrev Dmitry Yemanov såhär:
> 13.04.2011 15:39, Alex Peshkoff wrote:
>
>> Services API?
>
> This would get my vote. I'm just unsure how much happy users are going
> to be with this solution.
If client component sets expose the API in an easy-to-use manner, I
assume most users
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 availab
Den 2011-04-13 14:24 skrev Alex Peshkoff såhär:
> On 04/13/11 16:02, Kjell Rilbe wrote:
>> 3. The conf could include a GUID for each alias, allowing apps to find
>> their alias(es) in a more precise way than by name.
>
> And where do they arrive from in text file, edited by hand?
Yes, it would b
On 04/13/11 10:58, Alex Peshkoff wrote:
> Certainly. I will add separate public .h for C++ wrappers over
> interface-based API.
Sorry, looks like I have nothing serious to add now :-) Your code
required almost no modification after moving all 4 parts of the message
to the single structure. FYI it
Problem upgrade to FIREBIRD 2.5 (from 2.1)
--
Key: CORE-3441
URL: http://tracker.firebirdsql.org/browse/CORE-3441
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Version
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). When
> -Original Message-
> From: Alex Peshkoff [mailto:peshk...@mail.ru]
> Sent: Miércoles, 13 de Abril de 2011 9:07
> To: For discussion among Firebird Developers
>void fini()
>{
>if (bufferLength)
>{
>buffer = new u
35 matches
Mail list logo
