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

[Scott McKellar]

--- Mike Rylander <mrylander at gmail.com> wrote:

<snip>

> > >From what little I know about shared libraries -- all of which I
> > learned about fifteen minutes ago, after cracking open a book from
> > my shelf -- the function in question wouldn't have to have any
> > specific name like "handle_extension".  It could have any valid
> name,
> > as long as it had the right signature otherwise.
> >
> 
> Pinning the name is not required, but it would simplify the
> implementation of any one command to the point of "implement a
> function called X with a signature of Y" and then giving it any
> non-conflicting name in the config file.
 
<snip> 

> > Consequently we could plug in multiple functions without conflicts,
> > as long as none of their names collided.
> >
> 
> We could, but making sure we don't have collisions across arbitrary
> modules without allowing for user (config file) adjustment of the UI
> name to resolve conflicts would mean (in the extreme) having some
> sort
> of registry.  Allowing the UI-level name to be anything unique in the
> config and then pointing to a single method per dl seems, to me, the
> simplest way to avoid conflict -- assuming we go with a dl approach
> at all.

So shared libraries could give us more flexibility than we need or
want.  I'm not sure how much flexibility you're proposing.  I can
think of at least three different ways that the mechanism could work.
The configuration file could say any one of the following three 
things:

1. "In order to find the handle_login() function, look in xyz.so."

In this case both the functionality and the function name are fixed.
All that changes at run time is where to find the function.

2. "In order to log in, call the function named 'xyz_login' in 
xyz.so."

In this case the functionality is fixed, but the function name is
defined at run time, as well as its location.  This level doesn't
offer any obvious advantage over the first one.

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.)

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.

Scott McKellar
http://home.swbell.net/mck9/ct/