Hi Ben, > 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?
I forgot to answer this question when you asked it; right now Grant and I are focused on thinking about architecture at a different level than this, but I think in a week or two it would be great to have an IRC meeting. Beyond that, we're pretty flexible about timing. What timezone are you in? Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
