Some initial comments on a few things I've looked at so far:
I noticed that for onSearchBegin(), a sub-plugin (?) defines search(), for onReceiveKey(), a sub-plugin defines receive(), and for onProcessTrigger(), a sub-plugin defines trigger(). I found it a little odd that for onInit(), a sub-plugin defines onInit() -- similarly for onSetStrValue(). I think init() [if that's possible] seems somehow better-fitting in terms of naming -- either that or change all of the other things to match the names used by fscript.js. Or may be some other idea? What do you think?
I'm not so clear on how fscript.js/onSetStrValue() should behave -- specifically, the return value seems to get decided purely on whether a single sub-plugin returns true. Is that what we want? What if more than one sub-plugin returns a value and one returns true while another returns false? May be the current implementation is what we want -- which would be fine by me, I just don't currently have a sense of what it should be
onInit() in the original fscript.js took a single parameter iirc, in the most recent code candidate the sub-plugin's onInit() doesn't take a parameter. I wonder whether mirroring the original interface is preferable or not. May be it's not a big deal. Any thoughts?
I'm not sure about loading all fsubscript*.js files -- I wonder whether the loading order might matter in some cases and with the way the code is currently, a sub-plugin writer can only control this based on coming up with appropriate filenames. I hadn't really thought about multiple files per sub-plugin so I start to wonder about the potential consequences and alternative designs