On Oct 8, 2007, at 16:02 , Marco Pesenti Gritti wrote: > On 10/8/07, Bert Freudenberg <[EMAIL PROTECTED]> wrote: >> No idea, I did not quite get how the new regime works. Could you >> please explain it at >> >> http://wiki.laptop.org/go/Activity_DBus_API > > Well, I'm not sure it make sense to explain it there, since DBus is > not involved in it anymore.
This page is the only existing low-level documentation of what an activity is. We can certainly rename it, but this is the place where it needs to be documented. If you don't do it, I will have to reverse- engineer Sugar again and document it. Wouldn't be the first time. > See the Exec field explanation on > http://wiki.laptop.org/go/Activity_bundles > > When starting an activity instance Sugar is now just launching the > command line specified by the Exec activity.info field, adding > --activity-id and --object-id to it. This just work for activities > that supports multiple processes. > > Activities that doesn't support multiple process will have to > implement some sort of IPC to ensure process uniqueness. That means all instances of one activity run in the same security container? Otherwise, what methods are ther efor cross-container IPC? > The way this > is usually implemented in desktop application (firefox, evince, totem > etc) is: > > * Instance1 starts, see that there are not previous instances running > and open Window1 > * Instance2 starts, see that Instance1 is running and requests it to > open Window2 > * Instance2 exit > > The idea is that in general activities should support multiple > processes. But for Web and Etoys we are going to special case Rainbow > to allow this. Actually, Etoys uses multiple processes even now (sugar-native- factory used to fork end exec). We only always wanted to switch to single-process in the future for performance reasons. - Bert - _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
