On 07/01/14 22:40, Dimitry Sibiryakov wrote:
And out of curiosity: what IPluginModule::getModule() is supposed to
return and why it
may be called at all?
>> self
> But calling code already has this pointer. What's the point?
>
Because all our interfaces are derived f
> -Original Message-
> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
> Sent: Martes, 01 de Julio de 2014 22:22
>
>
> Frank,
>
> Please don't mess with obj.h for ISQL support.
>
> I think you should do it different, for example, passing extra
> parameters instead of th
Frank,
Please don't mess with obj.h for ISQL support.
I think you should do it different, for example, passing extra
parameters instead of the new constants.
Adriano
On 26-06-2014 13:14, f...@users.sourceforge.net wrote:
> Revision: 59774
> http://sourceforge.net/p/firebird/code/597
At 06:46 a.m. 2/07/2014, Mark Rotteveel wrote:
>In various places of the Firebird wire protocol and the Firebird sources
>the term 'incarnation' is used. What does this mean?
(fig.) Bringing into existence; (lit.) Embodiment in human flesh.
Helen
---
On 1-7-2014 20:56, Ann Harrison wrote:
>> In various places of the Firebird wire protocol and the Firebird sources
>> the term 'incarnation' is used. What does this mean?
>
> For cross-version compatibilty, most objects have a version number, sometimes
> called "incarnation". Objects that have no
>
Mark,
> In various places of the Firebird wire protocol and the Firebird sources
> the term 'incarnation' is used. What does this mean?
For cross-version compatibilty, most objects have a version number, sometimes
called "incarnation". Objects that have not changed will be zero. At least
In various places of the Firebird wire protocol and the Firebird sources
the term 'incarnation' is used. What does this mean?
For example for op_info_database, the struct on the Firebird side has:
typedef struct p_info
{
OBJCT p_info_object; // Object of information
USHORT p_i
01.07.2014 20:05, Alex Peshkoff wrote:
>>> You are wrong - module may (and does - Win_Sspi) contain >1 factories.
>> > Which means that each of them can perform its part of cleanup or only
>> > one of them can
>> >do cleanup - it is up to plugin developer. I still see no point in single
>> >c
On 07/01/14 20:15, Dimitry Sibiryakov wrote:
> 01.07.2014 18:06, Alex Peshkoff wrote:
>> On 07/01/14 16:36, Dimitry Sibiryakov wrote:
01.07.2014 14:24, Alex Peshkoff wrote:
>> 1. It must be single instance per module, therefore may be used as an
>> unique marker for it.
I saw
01.07.2014 18:06, Alex Peshkoff wrote:
> On 07/01/14 16:36, Dimitry Sibiryakov wrote:
>> >01.07.2014 14:24, Alex Peshkoff wrote:
>>> >>1. It must be single instance per module, therefore may be used as an
>>> >>unique marker for it.
>> > I saw nowhere this requirement is written.
>> > Plugi
On 07/01/14 16:36, Dimitry Sibiryakov wrote:
> 01.07.2014 14:24, Alex Peshkoff wrote:
>> 1. It must be single instance per module, therefore may be used as an
>> unique marker for it.
> I saw nowhere this requirement is written.
> Plugin factory, BTW has the same quality, so I really don't
On 01/07/2014 12:30, Dimitry Sibiryakov wrote:
> 01.07.2014 17:26, Adriano dos Santos Fernandes wrote:
>> We should decide what should happens with character sets and server-side
>> plugins. I talked specifically at external engines, but the same may be
>> valid for trace and whatever.
>>
>> Opinio
01.07.2014 17:26, Adriano dos Santos Fernandes wrote:
> We should decide what should happens with character sets and server-side
> plugins. I talked specifically at external engines, but the same may be
> valid for trace and whatever.
>
> Opinions?
Make them unicode-only as had been suggested m
Hi!
We should decide what should happens with character sets and server-side
plugins. I talked specifically at external engines, but the same may be
valid for trace and whatever.
My idea is that the ExternalContext should have a setCharSet method so
that server-side user code could set its own co
01.07.2014 14:24, Alex Peshkoff wrote:
> 1. It must be single instance per module, therefore may be used as an
> unique marker for it.
I saw nowhere this requirement is written.
Plugin factory, BTW has the same quality, so I really don't see a reason for
a separate
class.
Every plugin m
On 07/01/14 15:47, Dimitry Sibiryakov wrote:
> 01.07.2014 10:34, Alex Peshkoff wrote:
>> Interface IPluginModule is
>> not only for providing doClean function, it's a collection of
>> functionalities required for module, not instance.
> I see only doClean(), getVersion() and getModule(). What f
01.07.2014 10:34, Alex Peshkoff wrote:
> Interface IPluginModule is
> not only for providing doClean function, it's a collection of
> functionalities required for module, not instance.
I see only doClean(), getVersion() and getModule(). What functionality I
missed?
--
WBR, SD.
--
On 07/01/14 11:35, Dimitry Sibiryakov wrote:
> 01.07.2014 8:47, Alex Peshkoff wrote:
>> getMo_g_ule() is really missing, but getMo_d_ule(), returning pointer to
>> IPluginModule, is present in MasterImplementation::upgradeInterface()
> So far there is only one version, upgradeInterface() is not
On 07/01/14 11:38, Dimitry Sibiryakov wrote:
> 01.07.2014 9:08, Alex Peshkoff wrote:
>> The question is wrong - plugin's configuration is not necessary in
>> plugins.conf. But if you want to access configuration in default place -
>> use getDefaultConfig().
> Actually, I don't care what user co
01.07.2014 9:08, Alex Peshkoff wrote:
> The question is wrong - plugin's configuration is not necessary in
> plugins.conf. But if you want to access configuration in default place -
> use getDefaultConfig().
Actually, I don't care what user configured to be a storage of plugin config
- separat
01.07.2014 8:47, Alex Peshkoff wrote:
> getMo_g_ule() is really missing, but getMo_d_ule(), returning pointer to
> IPluginModule, is present in MasterImplementation::upgradeInterface()
So far there is only one version, upgradeInterface() is not ever called. And
even there
returned module is n
On 06/30/14 19:12, Dimitry Sibiryakov wrote:
> Hello, All.
>
> I see in sources this:
>
>> // This interface is passed to plugin's factory as it's single parameter
>> // and contains methods to access specific plugin's configuration data
>> class IPluginConfig : public IRefCounted
>> {
>> p
22 matches
Mail list logo
