[PEAK] PeakPlace, Junction

[Phillip J. Eby]

At 01:45 PM 12/7/03 -0800, John Landahl wrote:

>Coming soon: a shift to real messaging (e.g. full decoupling of method 
>calls from objects; messages used for pub/sub), SLP (rfc2608) 
>advertisement and discovery of messaging services, and some quality of 
>service guarantees (e.g. messages saved locally if unable to send, saved 
>on messaging server if unable to deliver), and communication alternatives 
>beyond PB (e.g. CORBA, PyRO, SOAP, XML-RPC, and there's no reason why IRC 
>or Jabber couldn't be used for pub/sub; even SMTP should be a possibile 
>transport).
>
>All comments and critiques are welcome.

A few quick thoughts:

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

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

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

* protocols.advise(instancesProvide=[]) works with Twisted interfaces, so 
you don't need to use __implements__ if you don't want to.  (You must first 
'import protocols.twisted_support', though.)

* As you noticed, though, Twisted interfaces don't currently work as PEAK 
configuration keys, (although Zope 3 interfaces do).  You'll need to 
implement an IConfigKey adapter for the Twisted interface types.  Take a 
look at peak.config.registries.InterfaceAsConfigKey for a starting 
point.  The only thing you need to do different is replace the getBases() 
call with something suitable for Twisted.  I should probably add this to 
PEAK myself, I just haven't gotten around to it.

If you create a 'component.xml' for your package, and define a simple 
section schema for your junction object, and declare that it implements 
'running.Task', you'll be able to use the PEAK EventDriven schema to run 
the application.  (Assuming you %import your package in the ZConfig file, 
and that you change Junction to do its startup chores 'uponAssembly', and 
not have it try to control the main loop.)

Note, by the way, that this means you can define a ZConfig abstract type 
for your client and server parts, and create section schemas for 
those.  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.