On 13. apr. 2010, at 01.35, KaiGai Kohei wrote: > >> I changed the signature for the existing "get_info" call to allow the engine >> to return an arbitrary number of features it support. >> If I remember correctly from your proposal you proposed this as a bitmask? >> Since this isn't going to be part of any time/space-critical loops, I think >> we shouldn't limit the design to a fixed number of features. > > Do you have a plan to provide guideline of the feature's signature? > Is it informed via feature_info->feature? or need to parse description? >
The intention is that we define different features as constants in the headerfile. People may however define their own feature sets that they want to be able to report, but is meaningless for others to care about... >> To make it even more "flexible" I decided to pass this as an array of >> features, >> each containing a value and a description. >> >> The next thing we need to do is to start "registering" different features :-) > > In your tree, default_engine.c and corresponding files are deployed at the > top level directory... I think an engine module has an individual directory > to store corresponding files, when we register different features. The default engine is special in the way that it is bundled with memcached. Other engines should be developed in separate git repositories... Cheers, Trond -- To unsubscribe, reply using "remove me" as the subject.
