Marco Pesenti Gritti
Tue Sep 26 08:31:13 EDT 2006
I've been thinking a bit about the simulator. Here is my current
thinking, thoughts are welcome.
1 Development aid. Recreating manually certain situation during
development takes time. Example: create an activity with a few buddies
in it to test the buddy list.
2 Stress testing. Being able to simulate the deployment networks with a
bunch of buddies and shared activities would help us finding bugs and
performance issues. A lot depends on the fidelity of the simulation but
even a reduced model would still be useful.
3 UI testing. The typical example is the mesh view. It's hard to figure
out how well it scales (and how to improve it) without having a
realistic number of buddies/activities on it.
4 Demos. Sugar has been designed for the mesh, running it on a single
machine can't give the idea of the actual user experience. Especially
with live cd's, it would be cool to keep a simulator running in the
background, to show off the features.
Test deployments could probably be a substitute for 3, maybe 2 wouldn't
be that necessary if we had good unit tests. For 1 and 4 simulation is
the only solution that comes to my mind.
A It should be easy to write simple bots. That way we can build complex
B It should be possible to have multiple bots per process (starting 3
processes for every buddy is not an option).
A and B are important especially for 3 and 4.
About A I'm considering a programmatic approach, something like:
kiu = Bot('kiu')
kiu.color = ....
kiu.icon = ....
chat = kiu.share_chat_activity('Chat title')
web = kiu.share_web_activity('OLPC', 'http://dev.laptop.org')
The various action would be queued up and executed on start.
About B. To be able to register multiple buddies (and their services) in
the same process we would need an owner-less presence service. Dan, do
you think supporting such use case is reasonable?
More information about the Sugar-devel