* morgs is here so... _ypod_ is 1cc still offline? * prakhar here here too * benzea is around hi! hello! here also. morgs: looks like polychronis is not online anymore <_ypod_> morgs: I'm here heh ahh his is back :) OK, shall we get started or wait a few more minutes? welcome to another round of the sugar meeting i think we can start we moved our time - to thursday and it looks like the regular atendees at least made it we have a special round today: collaboration so i hand the word to morgs OK. Our agenda is at http://wiki.laptop.org/go/Sugar_dev_meeting#Thursday_April_17_2008_-_17.00_.28UTC.29 Firstly, who wants some background on the collaboration framework? what does this include? There's a diagram at http://wiki.laptop.org/go/Activity_sharing, and also one at http://wiki.laptop.org/go/Presence_Service * bemasc would like to know why ejabberd can't handle 200 users * 200 subscriptions, but AIM can handle 40 million users * 200 subscriptions morgs: nice diagrams - was not aware of them bemasc: Quick answer: We are using a shared roster on the jabber server right now, as you know, and also some patches. The shared roster obviously has scalability issues, and somehow there are stability issues on ejabberd, perhaps with our custom patches. bemasc: Process One is looking into the stability thing. The maximum number of people I've seen on a jabber server was about 170. morgs: you mean except Google Talk, which has millions? bemasc: jabber.org runs ejabberd with 100,000s of accounts. * sj_ (n=sj@1cc-dhcp-174.media.mit.edu) has joined #olpc-meeting * _sj_ (n=sj_@wikipedia/sj) has joined #olpc-meeting morgs: right, and they can each have a roster with 100 or more users. So 170*170 should be fine * eben_ (n=eben@1cc-dhcp-176.media.mit.edu) has joined #olpc-meeting ejabberd is supposed to be very scalable and very reliable, running on erlang... what I'm saying is, algorithmic "scalability" is clearly not the problem bemasc: All I can say is that multiple people are looking at different aspects of why it doesn't scale, and I'm not one of them :) * _bernie has quit (Read error: 113 (No route to host)) So: back to the framework. Telepathy is a modular framework for Instance Messaging and related things like video/voice/irc etc. * cjb (n=cjb@pullcord.laptop.org) has joined #olpc-meeting Can you quickly describe the shared roster, I don't know what makes it bad. garycmartin: OK. Mesh view is like a buddy list on an instant messaging client. Except that with IM you can add buddies by a Jabber ID or some sort of username. With OLPC presence, we don't have a way to add buddies by name, since the only unique ID is a rather random-looking thing. So, at this stage we show *everyone* on the server to you. That is like having everyone else on the server, on your buddy list. Now, with IM usually you have events like logging on to the server, logging off, going idle and coming back. bemasc: the problem is that some simple changes cause n² messages to be sent bemasc: and these changes happen very often In our case, every time you alt-tab or switch active (shared) activities, we send that out. daf: it should be O(n) as daf is saying. bemasc: should! yes * m_stone (n=mstone@teach.laptop.org) has joined #olpc-meeting bemasc: we are using Jabber ina bad way yay, looks like 1CC is back on line hey everyone,sorry to interrupt. I have very little idea about the agenda. so, i would be a passive participant today and will try to learn from your discussions. is it acceptable? prakhar: sure :) great :) * 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 bemasc: instance? morgs: the alt+tab thing If you alt-tab between shared activities your icon on other people's mesh view should jump between the different activities. morgs: thanks, I'm clear on the shared roster now :) morgs: oh, I didn't realize that. I definitely don't like that. <_ypod_> morgs: seriously? _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.) bemasc: Why not? The whole point of the mesh view is that people are shown with their current activities. (There was a bug in the snowflakelayout used in mesh view to cluster buddies around the activities) * |ypod| (n=ypod@1cc-dhcp-184.media.mit.edu) has joined #olpc-meeting eben_: I think it's a privacy violation bemasc: then share via invitation, and others won't see morgs: no bemasc: heh, then don't use Sugar. That's the entire design for the collaboration space, since the beginning. morgs: I don't want to tell other people I'm collaborating with which window has focus bemasc: Only people who have permission to join an activity will see you in it. bemasc: you don't want people to know you're *not* looking at their Chat :P morgs: yes, seriously 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. * dirakx (n=dirakx@190.24.129.6) has joined #olpc-meeting 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? what if you're talking to your girlfriend and also playing WoW? bemasc: it's not going to be on such a fine level of granularity. there's a reason why IM clients don't even have an option for this We're providing technology, not curing Attention-Deficit Disorder... bemasc: it'll likely be more like an idle message, which they do have. eben_: see my response on #6846 eben_: every IM client makes idleness optional, for exactly this reason and also provides two idleness settings: system idle and chat-client idle 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 morgs: sounds wise 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 eben_: yes, and they also provide extensive privacy customization, and expose almost nothing by default 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. The mesh view is meaningless without this info. eben_: if I am multitasking between three activities, I want my XO to appear next to all 3 activities my XO should disappear when I leave morgs: I like the idea, but should move to the mail list, other folks will want to comment I'm sure. bemasc: That's not consistent with the view....we don't duplicate icons. * eben has quit (Read error: 110 (Connection timed out)) bemasc: please submit a proposal to the mailing list. OK: Collaborative activities! <|ypod|> bemasc: I'm sure eben has thought about it more that we have, let's take it to the list I've made a page at http://wiki.laptop.org/go/Collaboration_Central for activity authors, since the rest of the info on the wiki is technical and spread out I want to show what's happening in the world of collaborative activities. So, please send me news, or add it to the page, etc. The page lists current collaborative activities. I've added the core ones. Others are welcome to add there too. It should help us to see who's using different methods of collaboration, like stream tubes, etc. Then, I want to build up a list of effective developer resources. The current Tubes Tutorial doesn't describe stream tubes yet, and doesn't go into d-bus tubes enough yet. So I'll be working on that. Also, Read is our example for Stream Tubes, and it has some reliability issues. It all shows that collaboration implementation in activities is... difficult. so 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. For example, Update.1's PS creates the Telepathy channels, whereas in Ship.2 the activity had to do that. Write and Browse still have the old code, and can be updated to use the simpler version using what PS already provides. I'm sure there are other, non-core activities that I haven't looked at yet, that also can do this. You can look at HelloMesh, which has the simplified version. Comments on this? * _ypod_3 (n=ypod@can-olpc-nat.media.mit.edu) has joined #olpc-meeting morgs: when appropriate, deprecation notices are nice. * kimquirk has quit () morgs: I don't know if anything's been obsoleted, but if it has, printing a warning would be good. * _ypod_ has quit (Read error: 104 (Connection reset by peer)) bemasc: OK (although in this case we added API, so there's nothing to deprecate except code in the activities...) 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. * _sj_ has quit (Read error: 110 (Connection timed out)) 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. (That's used by python activities, there are also users of the Presence Service D-Bus API itself such as EToys.) 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? _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 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 bemasc: at this stage we cache buddy objects 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 * m_stone has quit (Read error: 104 (Connection reset by peer)) * cjb has quit (Read error: 104 (Connection reset by peer)) * eben_ has quit (Read error: 104 (Connection reset by peer)) * eben (n=eben@1cc-dhcp-176.media.mit.edu) has joined #olpc-meeting <_ypod_3> bemasc: I see morgs: ok, but I also might be working on a Write document that was partially written by someone I've never met * eben lost connectivity for a couple minutes; will try to catch up. * cjb (n=cjb@pullcord.laptop.org) has joined #olpc-meeting <_ypod_3> is everyone back? 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... morgs: ok. * m_stone (n=mstone@teach.laptop.org) has joined #olpc-meeting bemasc: what was your concern? (sorry) (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. I have another thing to add: I want a trivial method for getting my own buddy object, something like sugar.presence.me(). bemasc: OK, that's _slightly_ easier than self._shared_activity._pservice.get_owner() :) bemasc: yes, those ideas sound useful. :) morgs: there are too many kinds of identifiers; I can't tell what that method returns. bemasc: it returns your buddy object. 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 _ypod_3: Can you talk to us about Cerebro? <_ypod_3> http://wiki.laptop.org/go/Cerebro#Collaboration * |ypod| has quit (Read error: 110 (Connection timed out)) <_ypod_3> this is the current set of primitives available _ypod_3: Is the plan to hook this up to Presence Service, or offer this as an alternative to it? * kimquirk (n=kimquirk@wireless-42.media.mit.edu) has joined #olpc-meeting <_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 _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 _ypod_3: can you point me to a copy of the resulting code? _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 _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 * _sj_ (n=sj_@1cc-dhcp-111.media.mit.edu) has joined #olpc-meeting <_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 ? ;_ _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> ;) * jdsimmons (i=3f49c745@gateway/web/ajax/mibbit.com/x-dc78f6e1a0180cce) has joined #olpc-meeting _ypod_3: so we are in a strange position with cerebro _ypod_3: when you say: "minimizes the set of required transmission before everyone gets an update or a file" _ypod_3: how is thi shandled? <_ypod_3> http://wiki.laptop.org/go/Image:Comparison1.png _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 _ypod_3: Are you using multicast? _ypod_3: thanks, so it does not increase linear - sustain after a certain number of nodes * jdsimmons has quit (Client Quit) <_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) * jdsimmons (i=3f49c745@gateway/web/ajax/mibbit.com/x-734d77bafec98d07) has joined #olpc-meeting <_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 _ypod_3: ok <_ypod_3> however, the advantage of efficient data transport translates to small messages like a user profile also ;) _ypod_3: So just as incompatible with power management as salut... looks like we need wake_on_multicast. morgs: cerebro _implements_ multicast using the mesh firmware's unicast capabilities <_ypod_3> morgs: not really because this is configurable OK _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 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 _ypod_3: in dense environments, it seems to me that Cerebro should determine that everyone else is 1 hop away _ypod_3: do you see this in your experiments? * cjb appears. <_ypod_3> bemasc: true OK, does anyone else have anything to add to our topic of Collaboration? Activity authors? I'd like us to entertain the idea that we don't constantly need presence information for at least the mesh link-local presence modes 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. 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 garycmartin: radar yes, specific plans no maybe it won't help. but, this sort of thing might get our wakeups down. cjb: (devil's advocate): but then updating the mesh view requires waking everyone else up 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" bemasc: at the moment, doing nothing at all would require waking everyone else up _ypod_3: okay, maybe more like a minute. I don't know. erikos: yes cjb: at the moment, everyone has to wake up every time the state of presence changes morgs: cool I'm trying to think about how we can avoid wakeups by showing that we don't currently care about other people's presence because we're in a solo activity or something like that <_ypod_3> cjb: I see * _bernie (n=bernie@88.255.15.198) has joined #olpc-meeting we need to do *something* that lets us have mesh without losing power management <_ypod_3> _ypod_3: good point 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. cjb: I don't think sharing is usable with a delay of more than 10 seconds, or maybe even 5. My activities are just sharing files (like Read does). I wish that was easier to do. 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. 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) _ypod_3: because I might want to join a shared instance that somebody else just created morgs: thanks :) in return i will update you side when i am done erikos: :) Or the teacher puts something on the class bulletin board and they grab it at their leisure _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 bemasc: but you won't find out about that shared instance unless you go to the mesh _ypod_3: but that requires waking everyone else up to see if they've done anything, every time anyone looks at the mesh bemasc: I think it's an issue of current focus. I don't think it's a net win <_ypod_3> bemasc: hmmm right ;) bemasc: good point. 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 _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 sounds good to me _ypod_3: if you can spread them out sufficiently, I agree cjb: I think joining and leaving can be "lazy" except for participants in the activity. Also, I think of "batching" rather than "spreading" * Tturk (n=tturk@158.227.0.240) has joined #olpc-meeting 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 ;) bemasc: yup <_ypod_3> cjb: I mean wake up once every second (or two) I still think "synchronized wakeups" are somehow useful "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 _ypod_3: right, but there should be a balance point _ypod_3: it takes us two seconds to wake up and go back to sleep. say, condense all "low-priority" presence exchange into a ten-second window every minute <_ypod_3> bemasc: should be investigated _ypod_3: this is why I'm saying that your current appoach is not reasonable <_ypod_3> cjb: oops I thought it was millisecs _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 ok :) <_ypod_3> cjb: let's think more about it <_ypod_3> back to collaboration activities? sure 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)? maybe I should explain what he workson he's the author of the Multi-pointer X Server (google mpx) which allows multiple input devices (pointers and keyboard) to appear on the same screen cjb: ooh :) so, you can have two xterms open, two mice and two keyboards plugged in, and each person is working independently in different windows so, that's cool, but it's also network-transparent, like the rest of X we could imagine a new model of collaboration in which you invite someone's *pointer* and keyboard to your screen and to e.g. play memorize, or share abiword, you instead do remote X and can each see other's pointer and keystrokes 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 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 cjb: but I think it's great for legacy collaboration it's true also, you don't get the file that you both worked on at the end of the collaboration automatically 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 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... cjb: that doesn't sound too hard. Cool. Back to Activities: Here's the current status that I'm aware of: * Browse: shares bookmarks. (Anything else planned?) morgs: not at the moment morgs: someone has a good idea? or is missing something * Read: Shares PDFs using stream tubes. Some reliability issues encountered, possibly naive use of http server Cerebro's Teleport would be just about the perfect solution for Read morgs: Read (and other activities) suffer from not knowing which peer (tube) is the "server" for the activity * Write: Has a hub (master) and spoke topology - if the original sharer leaves, *boom*. uwog apparently has an idea to elect a new master. cjb: yeah * Chat: uses Text channel not Tubes, although would need to add Tubes to send drawings / pictures when those are added One thing worth considering with read, for a "neat-future-feature" is some simple bookmark support. "shared read" seems pretty silly to me it's a ... "read-only" activity. There's nothing collaborative about it * Record: uses D-Bus tubes, needs some cleanup, should use stream tubes, doesn't share photos taken before the buddy joins bemasc: alternative ways to distribute the PDF would help - how's Distribute? bemasc: it's not read only if you can annotate ;) but I see the point. 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? Oh, so that reminds me, we might get a Status into PS, like an IM status or *cough* facebook status _ypod_3: yes, and then they start running servers too _ypod_3: and if the download fails, the client tries another server _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? _ypod_3: the activity code needs to be improved. Infrastructure-wise, depends on what you can provide :) _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. _ypod_3: so the answer to "are there plans?" is "Cerebro!" :) <_ypod_3> bemasc: I find this as hard to understand as tubes itself 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? _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 _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 _ypod_3: Yes, it would make some activities simpler. _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). Time to wrap this discussion up, I think, unless there are any other things to discuss? Meeting ends in 5... 4... 3... 2... 1... Thanks everyone for being around morgs: thanks for your time! 0.5 *boom* morgs: thanks for this nice introduction! it was nice intro thanks!!'