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

[Scott McKellar]

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

> 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"/>

Your first example would need only a very limited degree of
flexibility -- the command is the same as an existing command, but
its implementation is specified at run time.

The second example is another matter.  Neither "frobinate" nor
"blurb" corresponds to any existing command in srfsh.  This looks
more like my option #3, where arbitrary command names are mapped to
arbitrary actions, and srfsh doesn't know or care what those actions
are.

The tricky part is to design an interface for the plugin functions.
It needs to be generic enough but not so generic as to turn into a
monster.

My simple-minded notion is that, apart from a few little built-in 
commands like time and print, the purpose of srfsh is to send
messages to servers via jabber, and receive responses the same way.
We're looking for a way that it can do so on behalf of arbitrary
plugins.  For example:

For sending a message, srfsh would pass:

1. The original command, tokenized or otherwise.

2. A pointer to the osrfConfig for the configuration file, so that
the plugin can read any configuration parameters that it needs, 
possibly including some that are specific to that plugin.

Through pointers, the plugin would return:

1. The name of a server.

2. The name of a service offered by that server.

3. Optionally, a jsonObject to be serialized and sent to that server.

4. Optionally, a pointer to a callback function.

srfsh would format the message and send it to the designated server.
If the plugin had specified a callback function, srfsh would wait
for a response, and then pass the response to the callback function.
Otherwise it would just go on to the next input command.

In addition, we would probably want the plugin to have access to
existing routines for issuing error messages, manipulating JSON, 
growing growing_buffers, and so on.

My impression is that this sort of thing will involve a significant 
amount of complexity, and require a lot of careful design up front.
However I've never worked on a plugin architecture before, and I may
be imagining more difficulties than are really there.

If we were to step back a bit from this highly generic approach, we
could provide a plugin slot just for logging in, and maybe for a
few other specific operations.  The interfaces for these functions
would be narrowly defined for their specific needs.  We wouldn't
need a Swiss Army knife do-anything interface.

Another approach is to rebrand srfsh as oilssh or something, and 
move it from the OpenSRF tree to the OpenILS tree.  If somebody 
wants to use openSRF to run a snowmobile dealership instead of a
library, he can clone oilssh and modify it accordingly.

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