The only purpose of the launch function is to facilitate writing components 
that take arguments from the commandline.  If you don't want that -- just don't 
use it.

It sounds like you'd be happy with plain-old-Python, and what you really want 
is just to write a component which spans multiple files (modules)?  Just have 
one file as the "component interface" (has a launch function), which then has a 
bunch of import statements for the multiple other modules you use and accesses 
things in them (read globals, call functions, etc.) directly, as per 
Python-usual.

If the issue is that you don't want to use pox.py to start POX and instead want 
to embed POX in another application, this is pretty easy in recent versions as 
long as you're happy with a pretty simple scenario.  It's been a while since 
I've done it, but I think I basically just hacked up boot.boot() to make sense 
within the context of the app I was embedding into, and passed _do_launch() the 
name of a module in the "outer" application (it's kind of dumb that it needs to 
be imported by name, but hasn't been big enough of an issue to do anything 
about).

-- Murphy

On Aug 5, 2014, at 5:36 AM, Kim Manning <kmann...@gmx.com> wrote:

> Hi Murphy, others,
> 
> It's my understanding (from the wiki, etc) that POX is designed to be 
> launched from the command line only, with options given to individual 
> components on the command line as well. The wiki recommends that if you have 
> multiple components and this is getting unwieldy to create a base module 
> which launches them all - this is how I currently start POX.
> 
> What I would like to do is pass callbacks to the launch function of each of 
> the individual components. This is my current method:
> 
> 1) Possible functions are stored in individual modules each containing a 
> function called "callback" (say)
> 
> 2) From an external-to-POX python script (something like a configuration 
> script), I specify the callback function I want as a string 
> ("mypackage.function1")
> 
> 3) I start POX as a separate subprocess, with the string as a component 
> argument ("pox.py base_component --callback=mypackage.function1")
> 
> 4) In the launch function for base_component, I dynamically import 
> mypackage.function1 and store the callback() function from it - and use it 
> from there as required
> 
> ...which is a strange and awkward process to say the least. In my perfect 
> world I'd be able to start POX, from within my python script, and directly 
> pass these functions (and potentially other python objects, to keep this 
> general - essentially all I want is to avoid the conversion to command line 
> args) to my POX components.
> 
> Not sure what I'm expecting to get out of this email but maybe just 
> suggestions? Ideas? Am I doing this a very stupid way and there's a simple 
> solution available right now? More than happy to play with the POX code - I 
> had a look at pox.boot, briefly, but it seemed quite focused on the argv idea 
> so would require a bit of work. Maybe something like the boot function that 
> took, say, a python dict of args?
> 
> Would appreciate any comments you might have.
> 
> -- Kim

Reply via email to