I'm wondering whether it makes sense to add a multi-purpose getInfo() method similar to what we have in other interfaces. This would be consistent, even if looking too much "legacy".

Taking into account that IReplicator is received from IAttachment and has no additional properties (in contrast to ITransaction for example), personal getInfo() in it may be an overkill. A new item for IAttachment::getInfo() could be enough.

Don't you think there could be other replication related info items in the future? Statistics (number of replicated blocks / transactions / records), for example?

I suggest to take a look at all this from one more point - can attachment have >1 replicator? If not in v.4 - take into an account what can be later, in theory, etc. If yes - having getInfo() in IReplicator is close to unavoidable, cause different replicators may have different properties.

I expect to have multiple replicators per attachment in the future.

In that case using getInfo() in attachment to obtain information about replicators would be very bad API - each time one will have to provide info about what replicator that info will be. Even list of protocols can be different - for example due to configuration issues.

Don't you think there could be other replication related info items in the future? Statistics (number of replicated blocks / transactions / records), for example?

So far I see no use for such items. All stats can be counted during block building and the block is either applied as whole or rejected.

different replicators may have different properties.

There is no way to set them. createReplicator() has nothing like Replication Parameters Block among parameters and the same configuration is unavoidable applied to all IReplicator instances created from the same IAttachment.

Now I start to question the idea about multiple replicators myself. The original goals I had in mind are:

1. parallel load of the single data stream
2. replication from multiple sources

(1) is not going to work in a single attachment due to its serialization. (2) may load multiple streams independently, but again not in the really parallel mode. This makes the whole idea rather useless, I'm afraid. Can we think of any other possible use for multiple replicators per attachment?

Why I like to have them is errors' handling. If separate instances of Replicator is used for each transaction and something bad happen you can just kill one instance and don't care about interference with others.

For single instance model the whole separate interface is meaningless and "process" method may become a method on Attachment or (even better) Transaction.

Well, given that we allow multiple transactions per attachment that cannot execute in parallel either, having multiple replicators looks consistent.

@aafemt, what particular format do you prefer?
<count><num1>...<numN> in no particular order? Ordered?
<numMIN><numMAX>?
Something else?

Taking into account the usage even simple <current> would be enough.
If application can use only too old protocol at max - asking is useless, an error on attempt to use it is enough. If application can use only too new protocol - the same. If application supports a range of protocols - the newest recognizable by server one is what is supposed to be used. That's why it is enough to know latest version supported by server.

And if you are going to have IReplicator::getInfo() call then separate items minProtocol and maxProtocol are better than single item with complex internal format.