On 7/23/07, Scott McKellar <[EMAIL PROTECTED]> wrote:
See remarks at bottom...
[snip]
> > 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 had considered that as well, though the login call we currently have is more complicated than a single opensrf method. And the md5-izing that happens between the two calls makes it even more complicated than just chaining requests (which is technically possible right now, using the relay mechanism).
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."
Heh ... I misspell most things I type.
>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.
Pinning the name is not required, but it would simplify the implementation of any one command to the point of "implement a function called X with a signature of Y" and then giving it any non-conflicting name in the config file.
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.
Exactly right. (See OpenSRF/src/libopensrf/osrf_application.c for examples.)
Consequently we could plug in multiple functions without conflicts, as long as none of their names collided.
We could, but making sure we don't have collisions across arbitrary modules without allowing for user (config file) adjustment of the UI name to resolve conflicts would mean (in the extreme) having some sort of registry. Allowing the UI-level name to be anything unique in the config and then pointing to a single method per dl seems, to me, the simplest way to avoid conflict -- assuming we go with a dl approach at all.
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()?
There are ways to expose those, yes. Some experimentation will be required, of course. :) [snip]
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".
I think this is what we'll end up doing until we decide on a good implementation. My gut says "simple dl's" ... but we shall see. Thanks, Scott. --miker
