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

Scott McKellar mck9 at swbell.net
Wed Jul 25 10:44:19 EDT 2007


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

> On 7/25/07, Bill Erickson <billserickson at gmail.com> wrote:
<snip>

> heh ... I'll say so.  One thing this drops, though, is the command
> renaming which would actually give us i18n for free.  I'm probably
> missing something, but what is all that infrastructure buying us that
> a simple config file controlled hash not?

Command renaming is kind of a separate issue from the use of plugins,
in the sense that we could implement it without implementing plugins
at all.  However if we want to do both they should be married to 
each other.

I think Bill's proposal would accommodate command renaming with, at
most, a little bit of tweaking.
 
> 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.

Probably if I knew more about plugin architectures, and about dynamic
functions generally, I would have a clearer picture in my head.

By all means if you want to do a quick patch as a demo or proof of 
principle, go ahead.  I have no immediate plans to submit any more 
patches to srfsh.c, so we won't be stepping on each other.

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

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



More information about the Open-ils-dev mailing list