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
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
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
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
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
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 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 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
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 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
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
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
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 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 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
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
>
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
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
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
---
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
> -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
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
22 matches
Mail list logo
