From: Manuel Nickschas <sputnick@quassel-irc.org>
Date: Wed, 21 Mar 2018 23:58:46 +0000 (+0100)
Subject: common: Represent core/client features as string list in the protocol
X-Git-Tag: travis-deploy-test~161
X-Git-Url: https://git.quassel-irc.org/?p=quassel.git;a=commitdiff_plain;h=9f91e0dd3c4eb5c2e2dedfc8d36a068d433d51b1;hp=9f91e0dd3c4eb5c2e2dedfc8d36a068d433d51b1

common: Represent core/client features as string list in the protocol

The previous way of representing all supported features as a bit-wise
combination of flags is reaching its limits, due to the fact that the
old Features enum didn't have a defined width, and thus the compiler
can (and does) choose to represent it as a 16 bit value even though
the serialization in the protocol is defined as a 32 bit value.

In order to solve this problem, and to make feature negotiation more
robust, a new field "FeatureList" is added to both "ClientInit"
and "ClientInitAck" handshake messages that holds a string list with
the supported features.

Clients still send both "Features" and "FeatureList" fields when
registering, in order to support older cores. The core now omits
the legacy "CoreFeatures" field if the client indicates support
for extended features. Support for extended features is indicated
as the legacy feature 0x8000.

Note that legacy features are a subset of the new extended features.
Clients supporting extended features are encouraged to send the
full list, including legacy ones, in their FeatureList field.

Internally, the string-based feature list is mapped to a
std::vector<bool> to provide for fast lookup of enabled features.
The new methods Client::isCoreFeatureEnabled() and Peer::hasFeature()
allow for convenient checking.

Both client and core now output a log message if there is a mismatch
between the peers.
---