On 06/30/14 17:50, Dimitry Sibiryakov wrote:
30.06.2014 15:44, Alex Peshkoff wrote:
On 06/30/14 17:40, Dimitry Sibiryakov wrote:
It makes issues with plugins harder to detect and diagnose.
Yes, but the reason was also rather strong - make it possible for
firebird to work in server,
On 06/30/14 19:25, Dimitry Sibiryakov wrote:
Hello, All.
Currently function getMogule() and IPluginModule itself is never used in
code. May be
it is not too late yet to kill the call and the class to decrease complexity
of
third-party plugin development?..
getMo_g_ule() is
01.07.2014 9:40, Alex Peshkoff wrote:
On 06/30/14 17:50, Dimitry Sibiryakov wrote:
30.06.2014 15:44, Alex Peshkoff wrote:
On 06/30/14 17:40, Dimitry Sibiryakov wrote:
It makes issues with plugins harder to detect and diagnose.
Yes, but the reason was also rather strong - make it
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
{
public:
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
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
- separate
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
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 ever
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.
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
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 many
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.
Opinions?
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 see a
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.
Plugin factory, BTW has
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 nowhere this
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
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 not
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
-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 the new
21 matches
Mail list logo
