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