-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mimi Yin wrote: | Hi Ben, | | An IRC chat would be good. Do you have any thoughts on discussion | topics?
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? - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjjsJ4ACgkQUJT6e6HFtqRXqgCeOEC5j6Hk9DdT3amdx3b0ofwE ko8An3j0J3XoyrdLWjsGhyk25bdENqEE =ov7q -----END PGP SIGNATURE----- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
