See remarks at bottom... --- Mike Rylander <[EMAIL PROTECTED]> wrote:
<snip> > While we're on the topic of the auth server, I just thought I'd throw > out there that I think we should remove the login functionality from > srfsh proper. It depends on an open-ils app, so it's wrong to ship > in > the base opensrf distro. > > That being said, it's much easier to use than doing the login dance > by > hand. Therefore I propose we create a simple plugin system. > Basically, we just add an element to the config file for srfsh that > allows for the specification of plugin commands via shared objects. > Imagine this in the config: > > <extention implementation="/openils/var/lib/authlogin.so" > command="login"/> > > srfsh would then dlopen the named implementation and when it saw a > command it didn't understand natively, but for which there was a > registered extention, it would call a function by the name of, say, > handle_extention in that dlopened lib, and the the function would be > required to have a definition of > > int handle_extention( char* words[] ); > > where the words[] array is the same as is used by all other handle_* > methods (with the exception of handle_request, which gets a relay int > (flag?)). > > For the login functionality, we can basically just move handle_login > to its own module (in the ILS svn), change the function name and > compile that against libopensrf. > > Eh? Thoughts? Actually I was about to comment that sfrsh.c still contained several hard-coded things that tied it to open-ils. You beat me to it. My own proposal was going to be much less ambitious. The config file would define whatever things are now hard-coded, such as names of services and methods. The user interface would be unchanged, and the underlying protocol would be unchanged, but the destination of the authentication requests, etc. would be defined at run time. I haven't tried to work out the details. I think you are proposing something more generic. It would handle not just existing commands such "login", but also whatever arbitrary commands anybody might dream up. For example an installation could implement a "dindle framistan" command by supplying a suitable shared library, a corresponding entry in the config file, and maybe a framistan server. Your specific proposal, however, is subject to a compelling and, indeed, devastating objection: you misspelled "extension." >From what little I know about shared libraries -- all of which I learned about fifteen minutes ago, after cracking open a book from my shelf -- the function in question wouldn't have to have any specific name like "handle_extension". It could have any valid name, as long as it had the right signature otherwise. We would get the name from the config file, or construct it according to some naming convention. After opening the library with dlopen(), we would look up the function by name by calling dlsym(). which returns a void pointer. We cast the pointer to a function pointer of the appropriate type and then call the function through the pointer. Consequently we could plug in multiple functions without conflicts, as long as none of their names collided. There's a lot I don't know about calling dynamic libraries. For example, if I call dindle_framistan() in a shared library, would it be able to access symbols from the calling executable, such as last_result (assuming it were declared extern) or a utility function like osrf_app_session_request_recv()? I hope so, because I would want srfsh to be able to perform services on behalf of the plugin. The present handle_* functions don't interact merely through parameters and return values. They access shared variables at file scope, and they call various other modules that maintain their own state internally. If a plugin couldn't access all the same goodies, it would be difficult for it to do what it needed to do. Another way to extend functionality would be to define servers and their interfaces dynamically. Instead of calling dindle_framistan(), we would format a message to a framistan server as specified in the config file, pass it through jabber. and await a response. This approach would require the framistan server to understand the OpenSRF way of doing things. On the other hand a shared library could do things any way it liked -- it could read an IMS database over SNA, if it came to that. It wouldn't have to know much about OpenSRF at all. Another option is to move handle_login() into a separate module that could be replaced by another implementation -- not at run time but at compile time. Finally we have the option of leaving things as they are. That's always the simplest and easiest option, for suitable values of "simple and easy". Scott McKellar http://home.swbell.net/mck9/ct/
