On 7/25/07, Bill Erickson <[EMAIL PROTECTED]> wrote:
On 7/25/07, Mike Rylander <[EMAIL PROTECTED]> wrote: > On 7/25/07, Bill Erickson <[EMAIL PROTECTED]> wrote: > > > > > > On 7/25/07, Mike Rylander <[EMAIL PROTECTED] > wrote: > > > On 7/25/07, Bill Erickson <[EMAIL PROTECTED]> 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
