On 7/23/07, Scott McKellar <[EMAIL PROTECTED]> wrote:
[snip]
3. "If the user issues a command spelled 'login', call the xyz_login function in xyz.so." In this case the very commands themselves are defined at run time, and can do arbitrary things not contemplated by the original design, subject only to the limitations of the function's interface. Another thought: the configuration file could say "The command for logging in is spelled 'login'". The functionality is fixed, but the name of the command is defined by the configuration file. That way the Francophones in Quebec don't have to use the barbaric Anglicism "login". They can "loginez" instead. (Yeah, that's probably even more barbaric. Whatever.)
This is what I was originally proposing, with the restriction that we allow only one extension function per .so. However, I'm not against allowing more than one function per .so as long as the function names are provided by the implementation and not calculated in some way. For instance, in our mythical config: <extension command="login" object="eg_extensions.so" function="oils_login"/> <extension command="frobinate" object="eg_extensions.so" function="blurb"/>
Option #3 above would inherently provide for this kind of command renaming. We might want to provide command renaming in any case, regardless of how we call the underlying functions, and not just for Quebec. I don't think it would even be very hard to do. It would just complicate the code a little with an extra layer of indirection. The defaults would remain what they are today, so existing users wouldn't have to change anything.
Actually, using the (built in) hash code there shouldn't be any extra indirection. Just dlopen() and dlsym() at load time and shove the function pointers into an osrfHash object keyed by the supplied command names. Then at run time, failing a matching built-in command (or if all commands move to a similar mechanism?) just check the extensions hash. --miker
