Provide public API for replication

[Olly Betts]

struct ReplicationInfo should probably be replaced by getter methods of DatabaseMaster and DatabaseReplica (for API consistency with existing classes and to permit other statistics to be added in the future without ABI breakage).

Setting milestone:1.1.1 for now - I'm currently intending to mark replication as "experimental" for 1.1.0.

[Richard Boulton]

I've already started work on a patch for this, so assigning to me - it'll probably need some review and replication may well need other changes, so marking it as "experimental" is a good plan anyway.

[Olly Betts]

This is really a blocker for releasing with replication, and having to disable that for 1.2.0 would be a shame and probably somewhat fiddly. Also there's a partial patch. Hence setting highest priority.

[Olly Betts]

Bumping to 1.1.4.

[Richard Boulton]

After some discussion on IRC, we've decided that the replication API isn't ready for a stable release yet. I have several significant concerns about it:

• the ReplicationInfo struct, as described in this ticket.
• there's no way to monitor progress of the replication operation through the API
• the file descriptor used for the replication communication is exposed via the API, which is a potential portability problem, and also simply rather ugly.
• the API generally offers little control over replication; it's really only designed for the command line scripts to use.

Rather than commit to supporting this API for several years, we'll remove it from the API now. Replication functionality will still be available in the 1.2.0 release via the scripts in bin, which have been tested in production environments and work well.

[Richard Boulton]

Replication API removed from public API in r13899 (for the bindings) and r13900 (for xapian-core).

Marking this ticket for the 1.2.x milestone, since a fix will no longer produce an API change.

[Olly Betts]

This isn't 1.2.x material now.

[Olly Betts]

Not a blocker for 1.4.0.

Exposing the fd is potentially an issue on Windows (where sockets are type SOCKET, which is essentially a pointer so may not fit in an int).

If we could just expose it as an opaque handle which fits in an int, we could map internally for such platforms.