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

[Mike Rylander]

On 7/23/07, Scott McKellar <mck9 at swbell.net> wrote:
> See remarks at bottom...
>

[snip]

> >
> > 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 had considered that as well, though the login call we currently have
is more complicated than a single opensrf method.  And the md5-izing
that happens between the two calls makes it even more complicated than
just chaining requests (which is technically possible right now, using
the relay mechanism).

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

Heh ... I misspell most things I type.

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

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

Exactly right.  (See OpenSRF/src/libopensrf/osrf_application.c for examples.)

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

> 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()?
>

There are ways to expose those, yes.  Some experimentation will be
required, of course. :)

[snip]

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

I think this is what we'll end up doing until we decide on a good
implementation.  My gut says "simple dl's" ... but we shall see.

Thanks, Scott.

--miker