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

[Mike Rylander]

On 7/25/07, Scott McKellar <mck9 at swbell.net> wrote:
>
> --- Mike Rylander <mrylander at gmail.com> wrote:
>

[snip]

>
> > If you guys want, I'll work up a quick patch to do login as I've
> > proposed.  I feel like I'm not explaining it well enough ... what I'm
> > thinking of is just much simpler than what either of you have
> > suggested thus far.
>
> I'm not worried about how to keep track of command names and function
> pointers.  I can think of various ways to do that, with various
> variations.
>
> I'm more concerned about how to make the plugins work once we have
> figured out how to find the right function pointers for them.  What
> does the plugin need access to, and how will it get it?  What will
> it need to pass back to srfsh, and how will it do so?  For a specific
> operation such a login we can cobble together whatever we need.  for
> something more generic, it's harder to decide what we need.

Each function (or, at the most, each module) should maintain it's own
state completely independent of others and of srfsh proper.  There's
no need to complicate anything beyond that.  If two modules need the
IDL, then they should each parse it ... it's not that much overhead,
and there's no need to prematurely optimize things like that.

As for accessing the core srfsh functions from within extensions, we
just call dlopen with 0 as the first parameter to get a handle to the
main program (global symbol table, actually) for use in dlsym().  That
could be MACRO-ified pretty easily to populate a set of
module-internal function pointers to core functions for quick
inclusion in any extension modules.

As for parameters and return values, I don't think that needs to
change.  We'll need to wrap access to the global last_result object in
a function, but that's trivial.  We could provide some simple "print
this JSON thingy" methods, but that too is not strictly required.

[snip]

>
> (My next pet project is to have opensrf report on the completion
> status if its child processes, so that an administrator can more
> readily determine that something crashed, and why.)
>

Rock.  That will be very helpful, thanks!

--miker