[OPEN-ILS-DEV] PATCH: srfsh.c (treatment of login_session)

[Mike Rylander]

On 7/23/07, Scott McKellar <mck9 at swbell.net> 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