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

[Scott McKellar]

See remarks at bottom...

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

<snip>

> While we're on the topic of the auth server, I just thought I'd throw
> out there that I think we should remove the login functionality from
> srfsh proper.  It depends on an open-ils app, so it's wrong to ship
> in
> the base opensrf distro.
> 
> That being said, it's much easier to use than doing the login dance
> by
> hand.  Therefore I propose we create a simple plugin system.
> Basically, we just add an element to the config file for srfsh that
> allows for the specification of plugin commands via shared objects.
> Imagine this in the config:
> 
>   <extention implementation="/openils/var/lib/authlogin.so"
> command="login"/>
> 
> srfsh would then dlopen the named implementation and when it saw a
> command it didn't understand natively, but for which there was a
> registered extention, it would call a function by the name of, say,
> handle_extention in that dlopened lib, and the the function would be
> required to have a definition of
> 
> int handle_extention( char* words[] );
> 
> where the words[] array is the same as is used by all other handle_*
> methods (with the exception of handle_request, which gets a relay int
> (flag?)).
> 
> For the login functionality, we can basically just move handle_login
> to its own module (in the ILS svn), change the function name and
> compile that against libopensrf.
> 
> Eh? Thoughts?

Actually I was about to comment that sfrsh.c still contained several
hard-coded things that tied it to open-ils.  You beat me to it.

My own proposal was going to be much less ambitious.  The config file
would define whatever things are now hard-coded, such as names
of services and methods.  The user interface would be unchanged, and
the underlying protocol would be unchanged, but the destination of
the authentication requests, etc. would be defined at run time.  I
haven't tried to work out the details.

I think you are proposing something more generic.  It would handle
not just existing commands such "login", but also whatever arbitrary
commands anybody might dream up.  For example an installation could
implement a "dindle framistan" command by supplying a suitable
shared library, a corresponding entry in the config file, and maybe 
a framistan server.

Your specific proposal, however, is subject to a compelling and,
indeed, devastating objection: you misspelled "extension."

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

We would get the name from the config file, or construct it according
to some naming convention.  After opening the library with dlopen(),
we would look up the function by name by calling dlsym(). which
returns a void pointer.  We cast the pointer to a function pointer
of the appropriate type and then call the function through the
pointer.

Consequently we could plug in multiple functions without conflicts,
as long as none of their names collided.

There's a lot I don't know about calling dynamic libraries.  For
example, if I call dindle_framistan() in a shared library, would
it be able to access symbols from the calling executable, such as
last_result (assuming it were declared extern) or a utility function
like osrf_app_session_request_recv()?

I hope so, because I would want srfsh to be able to perform services
on behalf of the plugin.  The present handle_* functions don't 
interact merely through parameters and return values.  They access
shared variables at file scope, and they call various other modules
that maintain their own state internally.  If a plugin couldn't 
access all the same goodies, it would be difficult for it to do what
it needed to do.

Another way to extend functionality would be to define servers and
their interfaces dynamically.  Instead of calling dindle_framistan(),
we would format a message to a framistan server as specified in the
config file, pass it through jabber. and await a response.

This approach would require the framistan server to understand the
OpenSRF way of doing things.  On the other hand a shared library
could do things any way it liked -- it could read an IMS database
over SNA, if it came to that.  It wouldn't have to know much about
OpenSRF at all.

Another option is to move handle_login() into a separate module that
could be replaced by another implementation -- not at run time but
at compile time.

Finally we have the option of leaving things as they are.  That's
always the simplest and easiest option, for suitable values of
"simple and easy".

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