So the model's base or metaclass would handle synchronization and the rest of the app would have to be effectively stateless with the cloud handling routing and instantiation inherently? That would work but be a big step form the way I'm working today where my model handles permanent storage and my resource instances handle non-persistent game data internally. Do you have a mailing list or wiki where you're laying out ideas? I'd be interested to join in on that.
- Andy
On Wed, Jul 2, 2008 at 10:50 AM, Andy FundingerHey Andy, I never replied to your question.
<Andy@newworldelectric.com> wrote:
> Cloud support would be nice. I have a twisted app(a web service to
> implement a game server for Second Life) that is likely to have a rough
> scaling curve with bursty usage. Atm I'm running it on a dedicated virtual
> box with plans to go to EC2 and then multiple EC2s, but a single cloud
> instance would be better. I've already got a decoupled permanent datastore
> which interfaces to SDB for a cloud should work from that angle too.
>
> What would twisted look like on a cloud? Would the main reactor still be
> single threaded with threads being distributed or would we have to
> rearchitect for multiple main reactors by port or path?
We've been discussing several ways in which this would be done, and so
far none of them would require application developers to do anything
too radical. By definition, if you are moving to a new architecture,
something needs to be re-architected :-) One solution that we've
prototyped simply involves creating a small "model" object and passing
it to a new service. In that instance there is very little that a
developer would have to do. With support for things like
auto-discovery and messaging, even that step might (in many cases) go
away and you'd just have to instantiate a particular service.
d
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python