(2010/04/14 11:26), Trond Norbye wrote:
>
> On 13. apr. 2010, at 17.54, KaiGai Kohei wrote:
>>
>> Example)
>> typedef enum {
>> ENGINE_FEATURE_CAS = 0, /**< has compare-and-set
>> operation */
>> ENGINE_FEATURE_PERSISTENT_STORAGE, /**< has persistent storage
>> support */
>> ENGINE_FEATURE_SECONDARY_ENGINE, /**< performs as pseudo engine
>> */
>> ENGINE_FEATURE_ACCESS_CONTROL, /**< has access control feature
>> */
>> NUM_OF_ENGINE_FEATURES,
>> } ENGINE_FEATURE_CODE;
>>
>
>
> This is exactly what I was meaning by registering the stuff in the headed
> file.
> I still want to be able to present this in a textual form to the user, so
> that's
> why I want to the description there.
>
> I know for sure that I got some ideas for thing I could want to put into a
> feature
> code in _my_ engines, but I'm pretty sure that they are meaningless to other
> folks.
> I don't want to inform the rest of the world about my private extensions, so
> I don't
> want to modify a public header. At the same time I don't want to hack my
> memcached
> server to be able to print the features in a more sane matter...
Indeed, the textual description might be necessary to log private extensions
also.
As long as we can have a common set of feature identifiers, I have no concerns
to implement my engine module.
OK, I'll begin to implement my engine module based on the current interface.
Please wait for while I'm working on. Thanks,
--
KaiGai Kohei <[email protected]>
--
To unsubscribe, reply using "remove me" as the subject.
