The internals of ATS has some static functions to convert from internal enum 
values to a descriptive string. This includes:

        HttpDebugNames::get_server_state_name()
        HttpDebugNames::get_event_name()
        HttpDebugNames::get_action_name()
        HttpDebugNames::get_cache_action_name()
        HttpDebugNames::get_api_hook_name()


I would like to expose these (and any future such Debug functions) to plugin 
APIs. A new one that would come to mind is a “id to overridable configuration” 
function (but, that’s for later). I think there’s at least two ways to do this, 
the first would be e.g.

  typedef enum
    {
      TS_HTTP_DEBUG_NAMES_NULL = -1,
      TS_HTTP_DEBUG_NAMES_SERVER_STATE,
      TS_HTTP_DEBUG_NAMES_EVENT_NAME,
      TS_HTTP_DEBUG_NAMES_ACTION_NAME,
      TS_HTTP_DEBUG_NAMES_CACHE_ACTION_NAME,
      TS_HTTP_DEBUG_NAMES_API_HOOK_NAME,
      TS_HTTP_DEBUG_NAMES_LAST_ENTRY
    } TSHttpDebugNamesType;

    tsapi const char* TSHttpDebugNameGet(TSHttpDebugNamesType name, int value);


This has the advantage that it’s really easy to extend with future additions, 
easy to use / remember, and trivial to implement. The downside is there’s no 
type safety on the “value” parameter other than the fact that the underlying 
methods (see above) deals with them.


The other alternative is to add one C function for each type, e.g.

    tsapi const char* TSHttpServerStateNameGet(TSServerState value);
    tsapi const char* TSHttpEventNameGet(TSEvent value);
    tsapi const char* TSHttpActionNameGet(int value);


This has better type safety (in most cases), but makes it slightly harder to 
use and extend.


Please discuss which would be preferable. There’s currently no compatibility 
concerns regarding this addition, it’s a brand spanking new API. But we should 
design it for future compatibility.

Cheers,

— Leif


        

Reply via email to