Public API for allowing custom Remote Protocol Server implementation

[German M. Bravo]

To be able to implement a Remote Protocol Server with only the xapian public API, four changes are needed:

• Add Xapian::Enquire::prepare_mset(): prepares an enquire to get a MSet. Xapian::Weight::Internal is filled with the statistics and a MultiMatch is initialized.

• Add stats serialisation methods: Xapian::Enquire::serialise_stats() and Xapian::Enquire::unserialise_stats(). These are used by MSG_QUERY and MSG_GETMSET.

• Add Xapian::MSet::serialise() and Xapian::MSet::unserialise(). Used by MSG_GETMSET.

• Add Xapian::RSet::serialise() and Xapian::RSet::unserialise(). Used by MSG_QUERY.

The implementation of a custom remote server is desirable for allowing integrations to expose a custom remote server protocol which will permit the creation of full-blown xapian servers with remote or clustering support to efficiently access indexes remotely. An example of such kind of server is Xapiand ​https://github.com/Kronuz/Xapiand

[German M. Bravo]

Fixed, it now passes all tests

[Olly Betts]

While this apparently passes all existing tests, there aren't any feature tests for the new API methods AFAICS.

[German M. Bravo]

I'm still not familiar with the tests policies, so I'm not really sure at all what tests would be desirable for this. At any rate, I have a fork of xapian in GitHub which has this (and my other patches) as single commits, those could be more up-to-date, I can't remember: ​https://github.com/Kronuz/xapian/commits/master

[Olly Betts]

I'm still not familiar with the tests policies, so I'm not really sure at all what tests would be desirable for this.

From HACKING:

2) Make sure the tests are right
--------------------------------

 * If you're adding a feature, also add feature tests for it.  These both
   ensure that the feature isn't broken to start with and detect if later
   changes stop it working as intended.

 * If you've fixed a bug, make sure there's a regression test which
   fails on the existing code and succeeds after your changes.

 * Make sure all existing tests continue to pass.

For a new API feature we want to be confident that it works as documented (and as intended!) and that future changes to the code which might break it will be caught before they get into a release, and ideally before they are even merged. Perfection in this regard is that the test suite exercises every line of the source code - that can be hard to fully achieve without disproportionate effort, but the other extreme of a new API method with no test coverage whatsoever is really not acceptable.

I was hoping to merge at least some of this before 1.4.2, but I'd like to get 1.4.2 into the next Debian stable release which basically means we're out of time, so I'm bumping the milestone.

[Olly Betts]

Ticket retargeted after milestone closed

[Olly Betts]

Ticket retargeted after milestone closed

[Olly Betts]

Moving to the 1.4.x milestone. It'd be good to merge this, but I'm not comfortable merging a feature of this scope without any feature tests, and it seems nobody's actively working on adding such tests.

[Olly Betts]

We're still lacking feature tests for the new API this adds.

[Olly Betts]

It's been 5 years since I explained the automated test requirements in detail and there's been no updates since, nor even an indication that any updates would be forthcoming, so I'm going to close this as incomplete.