11.06.2014 8:27, Alex Peshkoff wrote:
> May be you can say a few words about it? Where will be replication
> plugins plugged into firebird?
Into the engine. TRA_commit() to be exactly.
--
WBR, SD.
--
HPCC Systems
On 06/10/14 22:24, Dimitry Sibiryakov wrote:
>> When you asked about a way to iterate through a set of plugins - what
>> type of plugins did you talk about?
> Replication plugin.
>
May be you can say a few words about it? Where will be replication
plugins plugged into firebird?
---
10.06.2014 19:54, Alex Peshkoff wrote:
> Well, Dimitry in that case please explain what do you mean by 'what
> version should be assigned to plugin'. The only case when new version
> should be chosen is when new type of plugin added.
Right. That's what I'm trying to do now.
> When you asked ab
10.06.2014 21:54, Alex Peshkoff wrote:
> You are not completely right. Imagine someone adds own provider to
> firebird. And that provider except other features wants to load some
> modules to perform various user-specific code - that modules can be
> treated as firebird plugins, at least plugin ma
On 06/10/14 19:37, Dimitry Sibiryakov wrote:
> And once again about versioning: if in future versions you decide to add
> one more
> method to IVersioned interface, how it'll cope with your autoupgrade system?
Very bad - therefore we will not do it.
> I mean that
> new unknown methods are
On 06/10/14 20:24, Dmitry Yemanov wrote:
> 10.06.2014 19:37, Dimitry Sibiryakov wrote:
>
>> Actually, yes. I don't understand what you call "user types of plugins" and
>> their
>> difference from "system types", because support for any plugin type must be
>> coded in
>> engine code directly. I ca
10.06.2014 19:37, Dimitry Sibiryakov wrote:
> Actually, yes. I don't understand what you call "user types of plugins" and
> their
> difference from "system types", because support for any plugin type must be
> coded in
> engine code directly. I cannot imagine a way to work with plugin that
> pr
10.06.2014 15:57, Alex Peshkoff wrote:
> That's not about versioning, but about choosing a way to assign to
> plugins user types not conflicting with system types. Or having plugins
> of different types is also completely unnecessary?;)
Actually, yes. I don't understand what you call "user type
On 06/10/14 19:21, Adriano dos Santos Fernandes wrote:
> On 10/06/2014 08:42, Alex Peshkoff wrote:
>> What if we change PluginType
>> from unsigned to signed and let users' plugin types be negative (like
>> blob types)? Do you any problems here?
>>
>>
> Numbers are not a way to name things globally
On 10/06/2014 08:42, Alex Peshkoff wrote:
> What if we change PluginType
> from unsigned to signed and let users' plugin types be negative (like
> blob types)? Do you any problems here?
>
>
Numbers are not a way to name things globally in this world.
As you cited blob sub types, it's an example
On 06/10/14 15:51, Dimitry Sibiryakov wrote:
>> Now let me return to one more aspect. Adding own plugin types by users
>> was not taken into an account initially. What if we change PluginType
>> from unsigned to signed and let users' plugin types be negative (like
>> blob types)? Do you any proble
10.06.2014 13:42, Alex Peshkoff wrote:
> Choosing version is needed only f you add new type of plugin - for
> existing plugin types version number is already chosen.
And this is exactly what I'm trying to do.
> Now let me return to one more aspect. Adding own plugin types by users
> was not ta
On 06/10/14 14:19, Dimitry Sibiryakov wrote:
> Hello, All.
>
> What is the right method to choose subj for a new plugin? Should it be a
> sum of version
> numbers of all parent classes (ie IVersioned+IPluginModule+IBasePlugin etc)?
>
Choosing version is needed only f you add new type of p
Hello, All.
What is the right method to choose subj for a new plugin? Should it be a sum
of version
numbers of all parent classes (ie IVersioned+IPluginModule+IBasePlugin etc)?
--
WBR, SD.
--
HPCC Systems Ope
14 matches
Mail list logo
