On 7/25/07, Scott McKellar <[EMAIL PROTECTED]> wrote:

--- Mike Rylander <[EMAIL PROTECTED]> wrote:


[snip]


> 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.

Each function (or, at the most, each module) should maintain it's own
state completely independent of others and of srfsh proper.  There's
no need to complicate anything beyond that.  If two modules need the
IDL, then they should each parse it ... it's not that much overhead,
and there's no need to prematurely optimize things like that.

As for accessing the core srfsh functions from within extensions, we
just call dlopen with 0 as the first parameter to get a handle to the
main program (global symbol table, actually) for use in dlsym().  That
could be MACRO-ified pretty easily to populate a set of
module-internal function pointers to core functions for quick
inclusion in any extension modules.

As for parameters and return values, I don't think that needs to
change.  We'll need to wrap access to the global last_result object in
a function, but that's trivial.  We could provide some simple "print
this JSON thingy" methods, but that too is not strictly required.

[snip]


(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.)


Rock.  That will be very helpful, thanks!

--miker

Reply via email to