[Twisted-Python] Thinking Twisted (was Re: Need a mother?)

[Stephen R. Figgins]

Thanks for your responses, Jp and  Sean.

I hear you saying that if we need twisted.sister, we'll need to do some work
on it first.  It's a fixer-upper.  If we use it, and contribute to its
development, we might get some help from the twisted developers, who have
largely neglected it because no one is currently using it.

It also sounds like the primary task I want to put it towards, a central
naming service/message queue sort of thing may not be the right match for
twisted.sister.  Though if fixed up, I sounds like it could load balance
such a registry or an overtaxed component on my system.

I am beginning to question my model of what the system should look like.
This function seems basic to a distributed component system with a dozen or
more components.   Is anyone using Twisted.spread to implement such a
system?

Maybe my thoughts on this are too patterned on Corba.  I am seeing Twisted
as a lightweight asynchronous event-driven alternative to Corba, so I keep
trying to map it to that: where is the POA?  Where is the name server?

I would sure appreciate any help wrapping my head around the twisted way of
doing things.  The problem set is:

I want to create an n-tier application to manage stores in a vertical market
that has many changing yet strict federally mandated security requirements,
many interfaces to a variety of equipment (signature capture devices,
dispensing devices, etc.), and interoperate with different B2B business
partners.   

There is a limited set of services all stores will need, but each
store/chain will have its own service needs.  All stores/chains will need a
common subset of services, but will also need a specialized set of extended
services depending on their equipment, workflow and business partners.  The
clients need to be GUI and curses applications on Windows/Linux though
possibly with an option for some thin web browser clients.   Instead of
thousands of clients hitting a central application intermittently (like a
web server) Each store will have maybe a couple dozen clients that will
interact with the server almost constantly throughout the day.

It would be nice if the system could scale up (to multi-processor systems)
as well as out (to a server farm) for larger chains which may want central
hosting (though probably serving no more than a couple hundred stores.)


What would be the twisted approach to this?


Thanks, 

Stephen