[Chandler-dev] Chandler and Sugar
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Wed Oct 1 10:17:18 PDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Mimi Yin wrote:
| Hi Ben,
| An IRC chat would be good. Do you have any thoughts on discussion
That's a hard question. The best I've come up with is: "what can Chandler
and Sugar share?"
| On our end, it will probably be another couple of months before
| Grant / Jeffrey are ready to release the first round of work they've
| done on the re-architecture project. In the meantime however, I can
| familiarize myself a bit more with how things work in Sugar.
If you're interested in the design of Sugar, I'll certainly be happy to
answer any questions that I can. Also, Sugar developers, including the
lead UI designer, hang out in #sugar on irc.freenode.net. I'm not always
there, since I'm firewalled at work, but it's usually fairly active.
| One question that springs to mind is:
| Are you thinking of Chandler as an UI layer for managing all the user's
| data? Essentially providing a "task management / calendar" view that
| cuts across all your "Activities"? (I imagine that currently, this is
| the primary function of the Journal?)
| Or, would Chandler be one of the Activities that is logged in the Journal?
Your dichotomy is exactly right. Chandler makes most sense either as a
component of the system, somehow integrated with the Journal, or as an
Activity (basically just an application like any other). Ideally, I think
I would prefer the former. In Sugar, Activities run in a sort of isolated
virtual machine that prevents them from communicating with other
Activities or accessing user data unless explicitly authorized by the
user. This seems a bit unnatural for Chandler, which is designed to
manage the rest of the system. However, it's much easier to write an
Activity, which can be installed by the user and is little more than an
arbitrary Linux program, than to alter the Sugar system itself, which
requires modifications to the Sugar code.
I found Davor's suggestion to implement a Chandler backend that presents
an interface over D-Bus especially interesting. Sugar's architecture is
very much designed as a large number of independent programs that
communicate over D-Bus. Every Activity has a D-Bus service. Even the
collaboration system uses D-Bus, tunneled over the network by Telepathy.
If the Chandler backend could run as a D-Bus service, I suspect we could
make use of it most easily.
When would be a good time for the Chandler developers to meet?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the chandler-dev