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

[Mike Rylander]

On 7/25/07, Bill Erickson <billserickson at gmail.com> wrote:
>
>
> On 7/25/07, Mike Rylander <mrylander at gmail.com> wrote:
> > On 7/25/07, Bill Erickson <billserickson at gmail.com> wrote:
> > >
> > >
> > > On 7/25/07, Mike Rylander <mrylander at gmail.com > wrote:
> > > > On 7/25/07, Bill Erickson <billserickson at gmail.com> wrote:
> > > > >
> > > > > This is obviously on the side of "more work" ;)
> > > > >
> > > >
> > > > heh ... I'll say so.  One thing this drops, though, is the command
> > > > renaming which would actually give us i18n for free.
> > >
> > > I'm definitely missing something.  What's being i18n-ized in srfsh?
> >
> > Nothing directly, but if we allow the config file to define the
> > spelling of the commands, then everything (basically).  Imagine
> >
> >   <extension command="login" object="foo.so" func="login_func"/>
> >
> > for English, but replace it with
> >
> >   <extension command="connexion" object="foo.so" func="login_func"/>
> >
> > for French.
>
> I think of srfsh as a progromatic interface as much as a human-interaction
> interface.  Providing translations for script commands feels odd to me.  If
> we change "request" to "demande" for French (or "login" to "connexion"), how
> do we handle the existing srfsh scripts that call those commands explicity?
> We force the external scripts to pass en-US as the srfsh locale?

No ... there's no locale-iness there, just locally (re)defined strings
in the config file.  Supporting alternate command names is just a
side-effect of having user level command (re)naming.  And having such
(re)naming completely avoids the need for conflict resolution and
avoidance.  It also means that you can break your (and others)
scripts, but there's really nothing stopping an extension from using 2
or more names for the same function pointer, right?

Until/unless srfsh gets more/better handling of result objects (and
lots of other things, like control structures and loops and whatnot),
scripts are really just lists of commands to process serially.  That
does not diminish the need for the #! support (hell, I asked for it
originally) but I don't srfsh as a full-on programmatic shell ...
maybe it never needs to grow into that?  On the other hand, I can
imagine post-processing extensions that grab last_result and do ...
stuff. :)

In any case, I'm trying to think of the most bang with the least code.
 I haven't started on the demo patch yet, but the plan that's forming
looks something like:

1) add support for the following to the config parser:

  <extension object="foo.so" init="init_function">
    <command name="login" function="handle_login"/>
    <command name="connexion" function="handle_login"/>
  </extension>

2) turn that into a osrfHash of function names and pointers

3) look up and run unknown functions by name at the end of parse_request

4) add last_result() function wrapper

5) move handle_login out to it's own C module and compile as a .so

Then it's up to the extension author to document the values for the
init and function attrs ... I guess we could just have a well-known
init function, but I could imagine a single .so full of extensions
that all need their own init function.  That would be both simple and
possible when the config file is explicit.

I'll update when I've something to show... :)

--miker