[PEAK] PeakPlace, Junction

[John Landahl]

On Sun, 07 Dec 2003 19:32:11 -0500, Phillip J. Eby <pje at telecommunity.com> 
wrote:

> * Why does a junction usurp reactor functions?  How does this add value 
> over e.g. using EventDriven as a main program, into which a Junction is 
> added as a component?

This is a legacy issue.  Our program was initially using the OSE toolkit, 
but we needed something else which could provide more flexibility, 
security, etc., so we developed Junction as a replacement for the parts of 
OSE we were using.  Now that we have no OSE code left in our app we should 
change Junction accordingly (and change the app itself to use EventDriven 
-- something that's been on the to-do list).

>  To put it another way, why are there dispatch() and shutdown() methods 
> on IJunction?  (Note btw that Junction itself has a run() method, not a 
> dispatch().)

I was in the process of changing the terminology and neglected to update 
IJunction.

> Part of my point is that it means a Junction is not a reusable 
> component; you can't e.g. implement multiple junctions in one process 
> with different configurations.

That's a possibility that I hadn't considered.  My first reaction was to 
say that you wouldn't want to do that, but on second thought it opens up 
some really interesting possibilities for much larger applications.

> * I'm guessing that part of the reason you have the junction responsible 
> for the main loop is so you can do the client.connect()/server.listen() 
> calls.  But there's no need for that.  Instead, make server and client 
> responsible for starting themselves, with bindings flagged for 
> activation 'uponAssembly'.

True, and in moving our app away from OSE-based design considerations, 
this is definitely the way to go now.

> * Never instantiate a component as the default value of a binding.Make; 
> this will not work correctly if there is more than one instance of your 
> class.  (If there really is only one instance, make it a singleton; but 
> that's usually only sensible if it has no state.)

Where did you see this happening?

> ... you'll be able to use the PEAK EventDriven schema to run the 
> application.

Like I said, this has been on the to-do list.  We have other things for 
which AdaptiveTask would be very useful, as well, which was another reason 
to want to make the switch.

> ...
> Thus, users of your junction could "install" various "plugins" by 
> defining ZConfig schemas for their own components, and simply describing 
> them in a config file as subcomponents of the Junction.

This is also something I want to do with the code, specifically for 
providing new connection types (which will probably be renamed 
"endpoints").  Users would then be able to provide a list of endpoints in 
a ZConfig file (whether client or server endpoints), with the effect of 
allowing for multiple incoming and outgoing connections using various 
protocols.