[sugar] RE: Sugar Digest, Vol 8, Issue 36

Tue Feb 20 08:19:51 EST 2007

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: sugar-bounces at laptop.org [mailto:sugar-bounces at laptop.org] On Behalf
Of sugar-request at laptop.org
Sent: Monday, February 19, 2007 11:06 AM
To: sugar at laptop.org
Subject: Sugar Digest, Vol 8, Issue 36

Send Sugar mailing list submissions to
	sugar at laptop.org

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
	sugar-request at laptop.org

You can reach the person managing the list at
	sugar-owner at laptop.org

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 <robert.mcqueen at collabora.co.uk>
Subject: Re: [sugar] activity sharing protocol
To: Marco Pesenti Gritti <mpg at redhat.com>
Cc: sugar at laptop.org
Message-ID: <45D9AE52.4000507 at collabora.co.uk>
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 <robert.mcqueen at collabora.co.uk>
Subject: Re: [sugar] activity sharing protocol
To: Marco Pesenti Gritti <mpg at redhat.com>
Cc: sugar at laptop.org
Message-ID: <45D9AFEF.60201 at collabora.co.uk>
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 <mpg at redhat.com>
Subject: Re: [sugar] activity sharing protocol
To: Robert McQueen <robert.mcqueen at collabora.co.uk>
Cc: sugar at laptop.org
Message-ID: <1171896337.12867.20.camel at localhost.localdomain>
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 <jobbime at yahoo.fr>
Subject: [sugar] Python Version
To: sugar at laptop.org
Message-ID: <loom.20070219T153655-660 at post.gmane.org>
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 <mpg at redhat.com>
Subject: Re: [sugar] activity sharing protocol
To: Robert McQueen <robert.mcqueen at collabora.co.uk>
Cc: sugar at laptop.org
Message-ID: <1171897621.12867.29.camel at localhost.localdomain>
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 <robert.mcqueen at collabora.co.uk>
Subject: Re: [sugar] activity sharing protocol
To: Dafydd Harries <daf at rhydd.org>
Cc: sugar at laptop.org
Message-ID: <45D9CABE.8080005 at collabora.co.uk>
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
Sugar at laptop.org
http://mailman.laptop.org/mailman/listinfo/sugar

End of Sugar Digest, Vol 8, Issue 36
************************************