Steven, 1st of all sorry for my english in my previous posts, some words are missing and its hard even for me to read them.
my answer to your questions:
- i think '$CustomFunc' must be the name of universal metafunction to involve any custom function of any plugin. 1st parameter of $CustomFunc metafunction is string with plugin id. i don't know where is the best place to give mb that id: maybe in extended 'about' structure returned from plugin's Initialise() method, maybe in some separate method like 'mbApiInterface.Settings_RegisterVirtualTagFunctionPlugin(string pluginId)'.
- virtual tag function plugin must somehow export for mb ONE function: string VirtrualTagFunctions(string functionName, string trackUrl, params string[] p)
where p is OPTIONAL list of string parameters. I don't need these parameters right now, but i think its useful to implement them from the beginning.
- so we have:
[1] plugin must somehow register itself in mb as virtual tag function plugin. mb doesn't know what functions are supported by plugin, only users (and ofc. plugin developer) know their names.
[2] if mb encounters in virtual tag (and i hope in file organization templates, etc.) substring '$CustomFunc(somePluginId, somePluginFunctionName, <Tag1>, <Tag2>, some explicit string1, etc)', then mb calls plugin's 'VirtrualTagFunctions(somePluginFunctionName, trackUrl, params p1, p2, p3, etc)', plugin here is defined by 1st parameter of $CustomFunc, but this plugin id is not sent to plugin, its needed for mb only to know which plugin must be invoked. trackUrl must be sent to 'VirtrualTagFunctions()' by mb always automatically. mb substitutes substring '$CustomFunc(somePluginId, somePluginFunctionName, <Tag1>, <Tag2>, some explicit string1, etc)' by result of plugin function 'VirtrualTagFunctions()'.
[3] mb shouldn't validate plugin's function names and/or parameters. plugin itself must validate them. personally in MY case custom function names are just asr/alr preset names without optional parameters (except for track url, which is not optional).
[4] i don't know if its very difficult or not, but it might be very useful if $CustomFunc(pluginId, funcName, some optional text parameters) could have any nested mb native functions and/or nested custom functions in the optional parameter list (e.g. $CustomFucn(pluginId, funcName, some text, $Left(<Tag1>, 3))).
P.S. plugin id, function names and their parameters (if any) must be specified for USERS by plugin developer. MB itself doesn't need to know anything except for PLUGIN ID.
P.P.S. i dont know if its good solution, but plugin could send validation exception to mb by returning null intead of any (empty or not) string from VirtrualTagFunctions().