Problems with current design
- 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.
- 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 /somewhere-else/my-plugin.config @type=remap @tag=my-remap
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); } }