Hi. I am not an active participant in this group. I am a school psychologist in NC and I am also a computer student. I am taking two graduate classes- Human Computer Interaction and Ubiquitous Computing. I am wondering where I can go to get a summary of your "lessons learned" through your work on this project up to this point.
I would also like to devote some time to this project during the summer. Is there a way to arrange an internship? (I noticed that you wrote about the Nokia 800. I'd like to learn how that is used in schools. I work part-time in a setting for students who have severe disabilities. The communication devices available to them are very expensive. A $400.00 device would be reasonable, but still pretty expensive.) I was thinking on working on the OLPC project to create some applications for special needs students, especially those who have communication impairments and cognitive delays. A good number of the students I work with have severe autism. Many of the students come from families who have low incomes. Some of the families have more than one disabled child. Is this something that the project would consider? I am in the U.S.. Lynn Marentette TechPsych Interactive Multimedia Technology -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, February 19, 2007 11:06 AM To: [email protected] Subject: Sugar Digest, Vol 8, Issue 36 Send Sugar mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://mailman.laptop.org/mailman/listinfo/sugar or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Sugar digest..." Today's Topics: 1. Re: activity sharing protocol (Robert McQueen) 2. Re: activity sharing protocol (Robert McQueen) 3. Re: activity sharing protocol (Marco Pesenti Gritti) 4. Python Version (Jobbime) 5. Re: activity sharing protocol (Marco Pesenti Gritti) 6. Re: activity sharing protocol (Robert McQueen) ---------------------------------------------------------------------- Message: 1 Date: Mon, 19 Feb 2007 14:04:02 +0000 From: Robert McQueen <[EMAIL PROTECTED]> Subject: Re: [sugar] activity sharing protocol To: Marco Pesenti Gritti <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Marco Pesenti Gritti wrote: >> is known to work in resource-limited environments > > Just a curiosity, in which environments have it been used? On the Nokia 770 and N800 Internet Tablets, so 64/128MB RAM and 180/400MHz processors respectively. > 100 contacts seem too limited, or at least out of proportion with 30 per > activity. Maybe a more realistic proportion is 1/10. Our original thought was that the school would have one server, so ~1000 or somesuch, but Dan said that due to the need to split stuff up across RF channels, and the potential that a server would just be another laptop with maybe an uplink to other servers. So our working assumption currently is that we can have several servers in one school, each one serving ~100 users directly, and they can route to each other to see the other users. > Even assuming free JVM, is it worth to have a JVM installed/running for > just this? This is just for the server, but ejabberd looks like it has better support for PEP at the moment, and I think its less resource intensive than Wildfire anyway, so it'll be our first port of call. >> Question: if an activity exists but is not anyone's "current" activity >> (i.e., all buddies switched to a different activity but still have the >> inactive one running in the background), does the PS care about that >> activity at all? > > Totally. It should be still visible on the mesh view. Also there might > be cases of activities which could be evolving and exchanging data even > without active user participation. This was just us pondering whether it was worth buddies publishing all their current activities via the server, or just the active one. All of them isn't too much of a hardship. >> For bandwidth and scalability reasons, the PS will have to filter or >> not subscribe to some presence information for buddies. It needs to >> figure out which buddies and which activities are more relevant to >> Sugar and only deal with those. > > Can you elaborate about this please. Is it just an implementation > details or it effectively limit the information we will be able to > retrieve about a buddy. It's kinda an implementation detail, in that we need to put a limit on how many people the PS will collect/cache info for, and a limit on how much bandwidth it will use retreiving information, but to get this right we need a clearer idea of the people and activities we want to be able to show in the desired UI. We don't want a situation where the PS is pulling down info about 100s of buddies but sugar is choosing to show only a small fraction of them. >> one-to-one channels like an IM or a voice/video call can be made into a >> private activity > > I think activities are inherently social. There might be cases where > private can be used but it's gen2 stuff IHMO. This is just about mapping concepts. In Telepathy (and IM in general) you can get one to one messages and calls, and in the UI we only have concepts of activities, so we were thinking of "upcasting" these to activities to display in the UI. Otherwise we need a different way to represent these one-to-one tasks. >> do we need to migrate activites from the mesh to the server, and if so, >> how do we do it? > > I think this is an important use case. Kids could start activities at > home, in a small group, and then continue it at school, with other > buddies joining it. Implementation-wise, it's very hard to think of a sensible way to have an activity where some users are on the mesh and some are on the server, without ending up using someone as a relay, in which case why can't the other mesh users see the server using him as a mesh node? For migrating all of the mesh users to server users "atomically", this could be arranged by the PS looking at when all of the mesh people are visible through the server, and then arranging a migration then. >> are participants in an activity equal, or is there one person who is >> hosting each activity? > > I don't think there is one true strategy for this. I see it as activity > dependent. Yeah, I think thats what we thought too. >> what does the Sugar API look like? > > That's a very important question and one that we should figure out > early. I'd like to see at least a very general proposal about it. A > starting point could be the current presence service and the plan I and > Dan discussed. But it's unclear, for example, how the tubes will > integrate with it. The current concept is that the presence service will sheperd the Telepathy connections for XMPP and link-local, and pick up the buddies and activies that are deemed relevant, and make them available as Buddy or Activity objects for use from Sugar, similar to the current API. Where it differs is that rather than having Channels and Services exposed in the PS API, we just pass the Telepathy Channels involved up to the UI, and the other concepts (tubes) are exposed there and implemented by interacting directly with the backends. >> If you're sitting next to someone and want to make them your friend, >> but you're both on different mesh RF channels, you won't see them on >> the link-local. > > I'm unclear on how the network structure relates to the UI here. What I > was thinking is that you would just see the friend in the mesh view, > even if he is not on your local link. The problem is about finding people. If you're on mesh channel #6 and talking to a server on #6, and the guy who's sitting next to you is on mesh channel #11 and talking to /his/ server, even if you can talk to him via the server with IP routing, you're not going to see him on your mesh. I don't think it's very scalable to consider the presence service being aware of every single buddy within eg a school. Seeing everyone on your mesh, plus everyone you've marked as friends, and then maybe picking up some extras from the server, would be more reasonable. If you consider the potential traffic from them changing activity etc, so we think some "relevance" heuristic is necessary. But as a consequence of network topology you can end up not seeing the person next to you. :-/ >> How do we implement searching for people as described in the HIG? > > What issues are you seeing with this one? It could just be a search in > the presence service model (unless we want to avoid to fetch part of the > info about buddies). Yeah, this just follows on from the not having all the information about everyone all the time. You can search the people you can see over mesh easily because you get given the mDNS stuff all the time, but searching 1000 people on several servers is tricky. Jabber only has a concept of a User Directory which is searchable by name, alias and e-mail address. Do we need to build something better than this on the server in order to allow the PS to launch searches for people? >> Implementation plan > > I think it's difficult to discuss this before having an idea of what the > API will look like. There is code based on the existing presence service > and we need to figure out a migration plan. That's not quite the case. I think we have a reasonable idea of what shape the API will have, and we've identified some clear areas where we need to modify Telepathy spec/backends to provide extra features, so we can get started on some of this whilst the higher level stuff is nailed down too. > Marco Regards, Rob ------------------------------ Message: 2 Date: Mon, 19 Feb 2007 14:10:55 +0000 From: Robert McQueen <[EMAIL PROTECTED]> Subject: Re: [sugar] activity sharing protocol To: Marco Pesenti Gritti <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Marco Pesenti Gritti wrote: > I forgot an important question. Will all the communication have to go > through tubes or we will allow activity authors to use just the presence > service with their own communication stuff? (i.e. let the PS expose the > buddies ip) >From my perspective, not really. It's important to us that in Telepathy we provide the right primitives that it's very easy to get an existing TCP/whatever app (consider VNC via Telepathy or somesuch) working over tubes. This would probably take the form of being able to get the CM to expose the tube as a localhost TCP socket or Unix socket, and providing convenient API to represent this to your app, eg GIOChannels in Glib, whatever. In the long run the connection manager is going to get far more clever at eg NAT traversal and stuff than your app will be. For people who are writing an activity from scratch, I'd far rather provide higher-level contructs like D-Bus messages, even using the Python bindings to just have method/signal invocations, rather than people having to invent their own wire protocols and marshalling/serialisation etc. > Marco Regards, Rob ------------------------------ Message: 3 Date: Mon, 19 Feb 2007 15:45:37 +0100 From: Marco Pesenti Gritti <[EMAIL PROTECTED]> Subject: Re: [sugar] activity sharing protocol To: Robert McQueen <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain On Mon, 2007-02-19 at 14:04 +0000, Robert McQueen wrote: > >> do we need to migrate activites from the mesh to the server, and if so, > >> how do we do it? > > > > I think this is an important use case. Kids could start activities at > > home, in a small group, and then continue it at school, with other > > buddies joining it. > > Implementation-wise, it's very hard to think of a sensible way to have > an activity where some users are on the mesh and some are on the server, > without ending up using someone as a relay, in which case why can't the > other mesh users see the server using him as a mesh node? For migrating > all of the mesh users to server users "atomically", this could be > arranged by the PS looking at when all of the mesh people are visible > through the server, and then arranging a migration then. This sounds good. > >> what does the Sugar API look like? > > > > That's a very important question and one that we should figure out > > early. I'd like to see at least a very general proposal about it. A > > starting point could be the current presence service and the plan I and > > Dan discussed. But it's unclear, for example, how the tubes will > > integrate with it. > > The current concept is that the presence service will sheperd the > Telepathy connections for XMPP and link-local, and pick up the buddies > and activies that are deemed relevant, and make them available as Buddy > or Activity objects for use from Sugar, similar to the current API. > Where it differs is that rather than having Channels and Services > exposed in the PS API, we just pass the Telepathy Channels involved up > to the UI, and the other concepts (tubes) are exposed there and > implemented by interacting directly with the backends. > Sounds good. > >> If you're sitting next to someone and want to make them your friend, > >> but you're both on different mesh RF channels, you won't see them on > >> the link-local. > > > > I'm unclear on how the network structure relates to the UI here. What I > > was thinking is that you would just see the friend in the mesh view, > > even if he is not on your local link. > > The problem is about finding people. If you're on mesh channel #6 and > talking to a server on #6, and the guy who's sitting next to you is on > mesh channel #11 and talking to /his/ server, even if you can talk to > him via the server with IP routing, you're not going to see him on your > mesh. > > I don't think it's very scalable to consider the presence service being > aware of every single buddy within eg a school. Seeing everyone on your > mesh, plus everyone you've marked as friends, and then maybe picking up > some extras from the server, would be more reasonable. If you consider > the potential traffic from them changing activity etc, so we think some > "relevance" heuristic is necessary. But as a consequence of network > topology you can end up not seeing the person next to you. :-/ This needs to be discussed in detail with the design team. We needs to define what's the mesh meaning relatively to the network topology, to what search applies etc. And then base the implementation on these concepts. Tomorrow we have the weekly design conference call. Maybe you guys could join for at least part of it? I think it would be important to clear out the issues... > >> Implementation plan > > > > I think it's difficult to discuss this before having an idea of what the > > API will look like. There is code based on the existing presence service > > and we need to figure out a migration plan. > > That's not quite the case. I think we have a reasonable idea of what > shape the API will have, and we've identified some clear areas where we > need to modify Telepathy spec/backends to provide extra features, so we > can get started on some of this whilst the higher level stuff is nailed > down too. What I actually meant there is that it was difficult for me to comment on the implementation plan without having an idea of the API. Your answers above was helpful in this respect. > Basic multi-user chat, some regressions from existing presence service. What regressions do you anticipate? We hooked up a lot of the PS functionalities in the UI. One of the high priorities for Sugar is to get the Mesh infrastructure to work (both UI and network API) so that activity authors can start to use it. The sooner we get at that point, the better. > API for chats How this is different from tubes? Do we plan to have something chat specific? Finally, do you feel like making any time estimates on Phase 1/2. Not knowing enough about telepathy, I don't have any idea of how much work they would be. Thanks! Marco ------------------------------ Message: 4 Date: Mon, 19 Feb 2007 14:43:20 +0000 (UTC) From: Jobbime <[EMAIL PROTECTED]> Subject: [sugar] Python Version To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii Hi ! I'm not sure my last message was sent. I would like to know if it was possible to develop an application with Python2.4 in order to integrate it in Sugar. I am working with Fedora Core 6 and the Python packages are only available in version 2.4 and not 2.5. Can it cause any problems with the integration ? Jobbime ------------------------------ Message: 5 Date: Mon, 19 Feb 2007 16:07:01 +0100 From: Marco Pesenti Gritti <[EMAIL PROTECTED]> Subject: Re: [sugar] activity sharing protocol To: Robert McQueen <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain On Mon, 2007-02-19 at 14:10 +0000, Robert McQueen wrote: > Marco Pesenti Gritti wrote: > > I forgot an important question. Will all the communication have to go > > through tubes or we will allow activity authors to use just the presence > > service with their own communication stuff? (i.e. let the PS expose the > > buddies ip) > > From my perspective, not really. It's important to us that in Telepathy > we provide the right primitives that it's very easy to get an existing > TCP/whatever app (consider VNC via Telepathy or somesuch) working over > tubes. This would probably take the form of being able to get the CM to > expose the tube as a localhost TCP socket or Unix socket, and providing > convenient API to represent this to your app, eg GIOChannels in Glib, > whatever. In the long run the connection manager is going to get far > more clever at eg NAT traversal and stuff than your app will be. > > For people who are writing an activity from scratch, I'd far rather > provide higher-level contructs like D-Bus messages, even using the > Python bindings to just have method/signal invocations, rather than > people having to invent their own wire protocols and > marshalling/serialisation etc. OK, we have been saying to activity authors that just getting ip/port from the presence service would have worked so far. I guess we need to reconsider. I have two use cases in mind here: 1 Abiword collaboration 2 Develop activity using bazaar for code sharing. About 1 I suppose maybe making abi collab use telepathy could be a win for the desktop version too?;) 2 is more like a legacy issue... I'd really like uwog and orospark to comment directly on this! Marco ------------------------------ Message: 6 Date: Mon, 19 Feb 2007 16:05:18 +0000 From: Robert McQueen <[EMAIL PROTECTED]> Subject: Re: [sugar] activity sharing protocol To: Dafydd Harries <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii Dafydd Harries wrote: > Ar 19/02/2007 am 15:45, ysgrifennodd Marco Pesenti Gritti: >> On Mon, 2007-02-19 at 14:04 +0000, Robert McQueen wrote: >>> API for chats >> How this is different from tubes? Do we plan to have something chat >> specific? > > The idea is to use the existing Telepathy chat interface: More generally, Telepathy tubes are only intended for use when the underlying protocol /doesn't/ have a way of doing what you're trying to achieve. In the case of functionality that's intrinsic to the IM protocols we support, such as chat or voice/video calls (and maybe in future, file transfer), then Telepathy will have an interface for it, and the backend will implement that interface to allow you to access those protocol features in the native way for that protocol. > My guess is that the slowest part is going to be the Gabble modifications to > support PEP -- maybe a week or two. For Phase 1, yes. For Phase 2, we need to actually spec and implement the tubes stuff, which I wouldn't be quite so quick to decide was trivial. :) Regards, Rob ------------------------------ _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar End of Sugar Digest, Vol 8, Issue 36 ************************************ _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
