Problems with current design

1. The API makes it seem like remap plugins are very different from regular plugins but in reality it is not really, as remap plugins can do everything other plugins can. So having a different API doesn't make much sense.
2. It would be nice if plugin.config listed remap plugins as today one can easily overlook remap.config when trying to find all the plugins enabled on a given system.

Proposal

Specify remap plugins in plugin.config with a type tag

/somewhere/my-plugin.so @type=remap @tag=my-remap optional-argument-1 optional-argument-2

Optional arguments above should be treated as global settings for the plugin. They will be passed down to the plugin in TSPluginInit.

Use this tag as an abstraction to refer to remap plugins in remap.config

map http://somewhere/ http://somewhere-else/ @plugin-tag=my-remap @pparam=additional-param-1 @pparam=additional-param-2

Plugin returns a continuation for TS to invoke

When processing a remap rule during startup, TS will invoke a function in the plugin code that returns a continuation. This is the differentiating factor from today's implementation. We should also encapsulate the remap context information in a structure so that we can use it again during event handler invocation. It could look like

struct TSRemapContext {
  const char *plugin_tag;
  URL rule_from_url;
  URL rule_to_url;
  int rule_param_count;
  const char *rule_params[];
};

Plugin then receives this information and returns a continuation for TS to call.

TSCont TSRemapPluginSetup(TSRemapContext *remap_context);

The plugin is free to return the same continuation or different continuations for each invocation. The plugin can also store context information for this continuation using TSContDataSet.

Invoke the plugin via a continuation event just like regular plugins

int myEventHandler(TSCont cont, TSEvent event, void *edata) {
  if (event == TS_EVENT_HTTP_REMAP) {
    const TSRemapContext *remap_context = static_cast<TSRemapContext *>(edata);
  }
}