Collaboration Central/Sugar meeting Apr 17
Meeting Summary: April 17 2008
The full log is at: http://dev.laptop.org/~morgan/sugar_meeting_Apr_17.log
Background on the collaboration framework
Telepathy is a modular framework for Instance Messaging and related things like video/voice/irc etc.
- bemasc asked why ejabberd can't scale for OLPC collaboration when IM systems can handle "40 million users * 200 subscriptions".
- The answer is because at the moment you are subscribed to the presence of everyone on the server through a shared roster. The goal is to only see (subscribe to) presence for people you care about, and to search for others to add them. This will be implemented by Gadget.
- Since we publish the current (shared) activity, switching between activities with alt-tab results in traffic. This resulted in the next discussion:
Active activity in presence
* bemasc also doesn't think we should be broadcasting which instance is active, especially since it's not visualized on the other end <_ypod_> m_stone 's machine is online but m_stone himself is not here <morgs> bemasc: instance? <bemasc> morgs: the alt+tab thing <morgs> If you alt-tab between shared activities your icon on other people's mesh view should jump between the different activities. <garycmartin> morgs: thanks, I'm clear on the shared roster now :) <bemasc> morgs: oh, I didn't realize that. I definitely don't like that. <_ypod_> morgs: seriously? <morgs> _ypod_: yes, it has some bugs in the Update.1 display stuff but works at least partially there, and post Update.1 it should work (although I haven't tested myself.) <eben_> bemasc: Why not? The whole point of the mesh view is that people are shown with their current activities. <morgs> (There was a bug in the snowflakelayout used in mesh view to cluster buddies around the activities) <bemasc> eben_: I think it's a privacy violation <morgs> bemasc: then share via invitation, and others won't see <bemasc> morgs: no <eben_> bemasc: heh, then don't use Sugar. That's the entire design for the collaboration space, since the beginning. <bemasc> morgs: I don't want to tell other people I'm collaborating with which window has focus <eben_> bemasc: Only people who have permission to join an activity will see you in it. <morgs> bemasc: you don't want people to know you're *not* looking at their Chat :P <bemasc> morgs: yes, seriously <eben_> bemasc: If those you collaborate with are only in one of your activities, they will only know if you are or are not currently in that one. <bemasc> eben_: would you want your IM client telling the person you're chatting with whether or not the window has focus? <|ypod|> eben_: does the user at least have a choice as to not reveal this information? <bemasc> what if you're talking to your girlfriend and also playing WoW? <eben_> bemasc: it's not going to be on such a fine level of granularity. <bemasc> there's a reason why IM clients don't even have an option for this <morgs> We're providing technology, not curing Attention-Deficit Disorder... <eben_> bemasc: it'll likely be more like an idle message, which they do have. <bemasc> eben_: see my response on #6846 <bemasc> eben_: every IM client makes idleness optional, for exactly this reason <bemasc> and also provides two idleness settings: system idle and chat-client idle <morgs> OK, can we take this up on the sugar mailing list? It's a design issue since the beginning and we can't make progress on it in one discussion. <|ypod|> eben_: idle message makes sense, but has a several-minute timeout <erikos> morgs: sounds wise <eben_> I mean, you can argue that, but then you've also got things like Facebook and Twitter, which aim to update everyone about everything as quickly as possible. <|ypod|> eben_: but this is the user's choice to do so and here the user has no choice, anyway I agree with morgs <bemasc> eben_: yes, and they also provide extensive privacy customization, and expose almost nothing by default <eben_> I think just to make sure the Mesh view stays under control we'll want a timeout of about a minute or so. But Really, this collaboration topology is the foundation for sugar. <eben_> The mesh view is meaningless without this info. <bemasc> eben_: if I am multitasking between three activities, I want my XO to appear next to all 3 activities <bemasc> my XO should disappear when I leave <garycmartin> morgs: I like the idea, but should move to the mail list, other folks will want to comment I'm sure. <eben_> bemasc: That's not consistent with the view....we don't duplicate icons. <morgs> bemasc: please submit a proposal to the mailing list. <|ypod|> bemasc: I'm sure eben has thought about it more that we have, let's take it to the list
- Collaboration Central for activity authors, to show what's happening in the world of collaborative activities.
- Please send news to morgs or add it to the page
- Collaborative activities are listed with some notes, so you can get examples or see what the issues are - please list your own activities
- Developer resources for collaboration are listed and will be expanded
- Tubes Tutorial will get stream tubes written up soon
<morgs> the plan is to (long term) make it as easy as possible to introduce collaboration in an activity, by making Presence Service do as much as possible. <morgs> For example, Update.1's PS creates the Telepathy channels, whereas in Ship.2 the activity had to do that. <morgs> Write and Browse still have the old code, and can be updated to use the simpler version using what PS already provides. <morgs> I'm sure there are other, non-core activities that I haven't looked at yet, that also can do this. <morgs> You can look at HelloMesh, which has the simplified version. <morgs> Comments on this? <bemasc> morgs: when appropriate, deprecation notices are nice. <bemasc> morgs: I don't know if anything's been obsoleted, but if it has, printing a warning would be good. <morgs> bemasc: OK (although in this case we added API, so there's nothing to deprecate except code in the activities...) <morgs> Now that we are through Update.1, the next bit of API to simplify is converting between D-Bus names (in D-Bus tubes) and Buddy objects. <morgs> Currently all the activities have copied a _get_buddy function from Connect, which does this. That's a good candidate to go into sugar.presence, which is the client of Presence Service's D-Bus API. <morgs> (That's used by python activities, there are also users of the Presence Service D-Bus API itself such as EToys.) <bemasc> morgs: I want the ability to pass buddy objects through d-bus tubes, and also the ability to render buddy objects without introspecting them. <_ypod_3> bemasc: could you provide a use case scenario where you want to do that? <bemasc> _ypod_3: sure. I might want the user to be able to hover over a region of text in Write and see the XO icon of the user who is responsible for it <bemasc> that means that the far end had to transfer some object over the d-bus tube representing that XO, and the local side had to render the XO from that object <morgs> bemasc: at this stage we cache buddy objects <bemasc> as a coder, I don't want to have to worry about serializing and deserializing these things, or peering into them to get info about them <_ypod_3> bemasc: I see <bemasc> morgs: ok, but I also might be working on a Write document that was partially written by someone I've never met <_ypod_3> is everyone back? <morgs> bemasc: You have a point, but sounds like we need long term planning. We have enough stuff going for The Release Formerly Known As Update.2... <bemasc> morgs: ok. <eben> bemasc: what was your concern? (sorry) <bemasc> (13:39:46) bemasc: morgs: I want the ability to pass buddy objects through d-bus tubes, and also the ability to render buddy objects without introspecting them. <bemasc> I have another thing to add: I want a trivial method for getting my own buddy object, something like sugar.presence.me(). <morgs> bemasc: OK, that's _slightly_ easier than self._shared_activity._pservice.get_owner() :) <eben> bemasc: yes, those ideas sound useful. :) <bemasc> morgs: there are too many kinds of identifiers; I can't tell what that method returns. <morgs> bemasc: it returns your buddy object. <bemasc> morgs: but yes, I agree that this is a future-feature <_ypod_3> speaking of longer term goals, I 'd like to propose a simpler collaboration API
Polychronis told us about Cerebro:
<_ypod_3> http://wiki.laptop.org/go/Cerebro#Collaboration <_ypod_3> this is the current set of primitives available <morgs> _ypod_3: Is the plan to hook this up to Presence Service, or offer this as an alternative to it? <_ypod_3> morgs: not sure <_ypod_3> but currently I adjusted Chat to work with cerebro <_ypod_3> and it should be trivial to do the same for the rest of the activities <_ypod_3> that need collaboration <morgs> _ypod_3: that's like the original implementation of sharing, where we had a lot of telepathy code in the activity, and moved more and more into Presence Service... <_ypod_3> morgs: I actually removed half the code from the Chat activity in doing so <morgs> _ypod_3: can you point me to a copy of the resulting code? <morgs> _ypod_3: I've also removed a lot of code from Chat since PS now handles more <_ypod_3> https://dev.laptop.org/git?p=projects/cerebro;a=blob;f=apps/pippy_app.py;h=5f87e408b8af30572a7ca190dc0d5b459ed611de;hb=HEAD <_ypod_3> morgs: not sure if I used the latest version <morgs> _ypod_3: Thanks. For the benefit of everyone here, can you give us an overview of Cerebro: How it tracks presence and handles connectivity for activities? <_ypod_3> morgs: but, for example, the TextChannelWrapper class is no longer necessary <_ypod_3> morgs: sure <_ypod_3> cerebro is basically a set of 3 modules: presence information, data transport, collaboration <_ypod_3> the first step is to establish information about nodes that are present <_ypod_3> the second is to get the profile from them <_ypod_3> the profile includes personal info like nick, colors etc <_ypod_3> but also the activities that the user is currently sharing <_ypod_3> then each change in the user's profile triggers an update in the network <_ypod_3> now, the trick is that all interaction (including file sharing) is done using a mechanism that minimizes the set of required transmission before everyone gets an update or a file <_ypod_3> in the tests, 30 nodes are present and all share a chat session in a simple mesh scenario <_ypod_3> we are expanding the test to over 50 nodes <_ypod_3> everyone asleep by now ? ;_ <morgs> _ypod_3: sounds great - will be interesting to see how it handles stuff like Write documents with pictures, or Read PDFs - things that exposed issues in our current framework <_ypod_3> ;) <bemasc> _ypod_3: so we are in a strange position with cerebro <erikos> _ypod_3: when you say: "minimizes the set of required transmission before everyone gets an update or a file" <erikos> _ypod_3: how is thi shandled? <_ypod_3> http://wiki.laptop.org/go/Image:Comparison1.png <bemasc> _ypod_3: as I understand it, Cerebro pretends that the underlying mesh is the physics, and then implements a routing protocol over it, and then uses this routing protocol for presence information <_ypod_3> this diagram shows the time to share a 2MB file with up to 27 nodes <morgs> _ypod_3: Are you using multicast? <erikos> _ypod_3: thanks, so it does not increase linear - sustain after a certain number of nodes <_ypod_3> erikos: (let me try to go 1 by 1) it minimizes transmissions by making use of the layout of the network (information from the presence module) and by broadcasting data (which is broadcaste anyway because of the wireless medium) <_ypod_3> bemasc: true <_ypod_3> morgs: it is essentially multicast <_ypod_3> erikos: yes, I don't have number for more than 50 nodes yet, but this is my estimate <erikos> _ypod_3: ok <_ypod_3> however, the advantage of efficient data transport translates to small messages like a user profile also ;) <morgs> _ypod_3: So just as incompatible with power management as salut... looks like we need wake_on_multicast. <bemasc> morgs: cerebro _implements_ multicast using the mesh firmware's unicast capabilities <_ypod_3> morgs: not really because this is configurable <morgs> OK <bemasc> _ypod_3: actually, I don't know this... does Cerebro use TTL=1 multicast, or unicast? <_ypod_3> the presence information can be scattered over a period of time that is analogous to the number of nodes around you <_ypod_3> bemasc: it uses ttl=1 broadcast <bemasc> ok, so we do still need wake on broadcast <_ypod_3> but can fall back to unicast as an option <_ypod_3> bemasc: yes, but this can be done so that it won't happen regularly more than once a second <bemasc> _ypod_3: in dense environments, it seems to me that Cerebro should determine that everyone else is 1 hop away <bemasc> _ypod_3: do you see this in your experiments? <_ypod_3> bemasc: true <morgs> OK, does anyone else have anything to add to our topic of Collaboration? Activity authors? <cjb> I'd like us to entertain the idea that we don't constantly need presence information <cjb> for at least the mesh link-local presence modes <garycmartin> Is the sugar 'bulletin board' feature on any ones radar? Seems to me many activities can become group activities without any specific code on their part. <cjb> so, if I hit the mesh view, perhaps we could try to guarantee that I'll have almost all of the local presence info within ten seconds <morgs> garycmartin: radar yes, specific plans no <cjb> maybe it won't help. but, this sort of thing might get our wakeups down. <bemasc> cjb: (devil's advocate): but then updating the mesh view requires waking everyone else up <erikos> morgs: re authors: to update browse I can have a look in the latest hellomesh code right? <_ypod_3> cjb: "presence info in less than 10 secs" contradicts "get our wakeups down" <cjb> bemasc: at the moment, doing nothing at all would require waking everyone else up <cjb> _ypod_3: okay, maybe more like a minute. I don't know. <morgs> erikos: yes <bemasc> cjb: at the moment, everyone has to wake up every time the state of presence changes <erikos> morgs: cool <cjb> I'm trying to think about how we can avoid wakeups by showing that we don't currently care about other people's presence <cjb> because we're in a solo activity <cjb> or something like that <_ypod_3> cjb: I see <cjb> we need to do *something* that lets us have mesh without losing power management <_ypod_3> _ypod_3: good point <walter__> to Gary's point, the bulletin board really could (should) be a simple interface to sharing. It may be more a matter of the interface between the datastore and the collaboration model than anything else. <bemasc> cjb: I don't think sharing is usable with a delay of more than 10 seconds, or maybe even 5. <jdsimmons> My activities are just sharing files (like Read does). I wish that was easier to do. <bemasc> cjb: the teacher shares something with students, and then... everyone waits around for a minute for it to appear so they can join it? huge waste of time. <morgs> erikos: http://dev.laptop.org/git?p=projects/hellomesh;a=commitdiff;h=723ba547e4d7fe7ccca856b264b10cd9fdd291e6 and http://dev.laptop.org/git?p=projects/hellomesh;a=commitdiff;h=e6c15f7c77914bf8c30a119786413685ef19e30b <_ypod_3> bemasc: I think cjb is talking about some else here: why wakeup on network events if I'm not interested in them (lack of intereste expressed in running a stand alone activity) <bemasc> _ypod_3: because I might want to join a shared instance that somebody else just created <erikos> morgs: thanks :) in return i will update you side when i am done <morgs> erikos: :) <walter__> Or the teacher puts something on the class bulletin board and they grab it at their leisure <bemasc> _ypod_3: as a compromise, I would say: activity session creation needs to be fast. Invitations need to be fast. Most other things don't. <_ypod_3> bemasc: but this can be done once you press the mesh view <eben> bemasc: but you won't find out about that shared instance unless you go to the mesh <bemasc> _ypod_3: but that requires waking everyone else up to see if they've done anything, every time anyone looks at the mesh <eben> bemasc: I think it's an issue of current focus. <bemasc> I don't think it's a net win <_ypod_3> bemasc: hmmm right ;) <eben> bemasc: good point. <cjb> yeah, I think we can probably agree that there are useful ideas here <_ypod_3> bemasc: you have a point because if everyone becomes lazy to wakeups, noone will communicate effectively <bemasc> _ypod_3: I agree. However, creating new activity instances is rare, and invitations are unicast, so this shouldn't create many wakeups <_ypod_3> cjb: I still think that spreading out the wakeups in a dense environment is a good cost/benefit approach <cjb> sounds good to me <cjb> _ypod_3: if you can spread them out sufficiently, I agree <bemasc> cjb: I think joining and leaving can be "lazy" except for participants in the activity. Also, I think of "batching" rather than "spreading" <cjb> if you're saying that you want to spend two seconds awake every ten seconds, I'm not sure that's worthwhile <_ypod_3> bemasc: good point. So one can create network traffic by starting/stopping activities ;) <cjb> bemasc: yup <_ypod_3> cjb: I mean wake up once every second (or two) <bemasc> I still think "synchronized wakeups" are somehow useful <bemasc> "high-priority" presence (like activity creation) can be eager and trigger a wakeup. <_ypod_3> bemasc: this also tends to increase collisions thought and may defeat the purpose of waking up <bemasc> _ypod_3: right, but there should be a balance point <cjb> _ypod_3: it takes us two seconds to wake up and go back to sleep. <bemasc> say, condense all "low-priority" presence exchange into a ten-second window every minute <_ypod_3> bemasc: should be investigated <cjb> _ypod_3: this is why I'm saying that your current appoach is not reasonable <_ypod_3> cjb: oops I thought it was millisecs <cjb> _ypod_3: I'd like it for it to take us much, much less time, but that's where we are now <_ypod_3> cjb: no prob. this may actually be better <cjb> ok :) <_ypod_3> cjb: let's think more about it
<cjb> I think we have Peter Hutterer working for us now, by the way <_ypod_3> are there any suggestions from your experience with collaboration in terms of functionality that should be available to activities (such as Ben's suggestions)? <cjb> maybe I should explain what he workson <cjb> he's the author of the Multi-pointer X Server (google mpx) <cjb> which allows multiple input devices (pointers and keyboard) to appear on the same screen <morgs> cjb: ooh :) <cjb> so, you can have two xterms open, two mice and two keyboards plugged in, and each person is working independently in different windows <cjb> so, that's cool, but it's also network-transparent, like the rest of X <cjb> we could imagine a new model of collaboration <cjb> in which you invite someone's *pointer* and keyboard to your screen <cjb> and to e.g. play memorize, or share abiword, you instead do remote X and can each see other's pointer and keystrokes <cjb> anyway, I guess this is all I have to say. I think it's a pretty powerful kind of collaboration to run alongside what we have now. Peter's living in New Zealand and working from home under contract, I think <bemasc> cjb: Write is a great example of why this is not a universal model: with mpx you both have to work on the same piece of the document <bemasc> cjb: but I think it's great for legacy collaboration <cjb> it's true <cjb> also, you don't get the file that you both worked on at the end of the collaboration automatically <cjb> because you were really just sharing the other person's screen -- the file itself lives on their disk. so you'd need to enable document sharing to happen separately <morgs> Now we just need a way to invite someone's CPU to your activity :) * _ypod_3 dreams of force-feedback on the mouse and colliding pointers... <bemasc> cjb: that doesn't sound too hard. Cool.
Back to activities
<morgs> Back to Activities: Here's the current status that I'm aware of: <morgs> * Browse: shares bookmarks. (Anything else planned?) <erikos> morgs: not at the moment <erikos> morgs: someone has a good idea? <erikos> or is missing something <morgs> * Read: Shares PDFs using stream tubes. Some reliability issues encountered, possibly naive use of http server <bemasc> Cerebro's Teleport would be just about the perfect solution for Read <cjb> morgs: Read (and other activities) suffer from not knowing which peer (tube) is the "server" for the activity <morgs> * Write: Has a hub (master) and spoke topology - if the original sharer leaves, *boom*. uwog apparently has an idea to elect a new master. <morgs> cjb: yeah <morgs> * Chat: uses Text channel not Tubes, although would need to add Tubes to send drawings / pictures when those are added <eben> One thing worth considering with read, for a "neat-future-feature" is some simple bookmark support. <bemasc> "shared read" seems pretty silly to me <bemasc> it's a ... "read-only" activity. There's nothing collaborative about it <morgs> * Record: uses D-Bus tubes, needs some cleanup, should use stream tubes, doesn't share photos taken before the buddy joins <morgs> bemasc: alternative ways to distribute the PDF would help - how's Distribute? <eben> bemasc: it's not read only if you can annotate ;) but I see the point. <morgs> I think we need two modes of document sharing - async, like bulletin board style, and "What are you reading now?" <_ypod_3> so someone is running an http server and others get the file off it? <morgs> Oh, so that reminds me, we might get a Status into PS, like an IM status or *cough* facebook status <bemasc> _ypod_3: yes, and then they start running servers too <bemasc> _ypod_3: and if the download fails, the client tries another server <bemasc> _ypod_3: at least, that's how it's supposed to work. <_ypod_3> no wonder why it doesn't scale. Are the plans to replace this? <morgs> _ypod_3: the activity code needs to be improved. Infrastructure-wise, depends on what you can provide :) <bemasc> _ypod_3: the Telepathy developers have stated to me that file transfer is not a priority, because their clients (including OLPC) have not commissioned that feature, and there's no solid XMPP file transfer standard. <bemasc> _ypod_3: so the answer to "are there plans?" is "Cerebro!" <cjb> :) <_ypod_3> bemasc: I find this as hard to understand as tubes itself <morgs> bemasc: file transfer was implemented for Telepathy last year as a GSOC project, but not for all CMs and has of course bitrotted - so it's not far off, just not on the list of priorities... <_ypod_3> morgs: is Scalability _not_ on the list of priorities? <morgs> _ypod_3: File Transfer is a Feature... Scalability mainly involves spending time Not Adding Features... or am I being cynical? <_ypod_3> morgs: but we don't have scalability even without file sharing <morgs> _ypod_3: That's where you come in. :) <_ypod_3> _ypod_3: and I disagree that file sharing is a feature! <_ypod_3> morgs: file sharing is just as important as presence: you need to know "who" is around and you need to be able to exchange "something" with them <morgs> _ypod_3: Yes, it would make some activities simpler. <morgs> _ypod_3: As I understand it, the sharing infrastructure people include you, m_stone + collabora. I'm now focusing on activities. So, thanks for raising it - but I can't take it further. Let's take it to the mailing list(s).