Couple of questions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Couple of questions

Mike Hearn-3
Hiya!

First question - the Sugar mockups have little avatar photos in the
buddy list. How are people with no digital cameras supposed to get
such a thing?

    http://wiki.laptop.org/go/Image:Sugar.png

Second question - the Presence DBUS service bears a strong resemblence
to the Galago presence service. Is there some reason you're creating a
new one?

thanks -mike
Reply | Threaded
Open this post in threaded view
|

Couple of questions

Marco Pesenti Gritti

>
> Second question - the Presence DBUS service bears a strong resemblence
> to the Galago presence service. Is there some reason you're creating a
> new one?

Hi Mike,

so far our main focus has been about developing user experience ideas,
iterating over them, experimenting. In that context it was easier to
build quick prototypes than to go through the effort of extending
existing frameworks.

When our ideas about the user experience and the framework will mature
and settle down we will be looking at the best way to implement them.
Which, in many cases, involves reusing and extending existing projects.

This is a gradual process and it already started to happen... We are now
using Xephyr for the display emulation, Matchbox/libwnck for window
management. I'm looking into Clutter (unaccellerated OpenGL problem aside).

Dan Williams has been looking into Telepathy/Galago. He will surely post
about his findings when he is back from vacation... For now you can have
a look to my brainstorming about it:
http://mailman.laptop.org/pipermail/sugar/2006-July/000044.html

Marco
Reply | Threaded
Open this post in threaded view
|

Couple of questions

Dan Williams-4
In reply to this post by Mike Hearn-3
On Fri, 2006-07-21 at 22:48 +0100, Mike Hearn wrote:

> Hiya!
>
> First question - the Sugar mockups have little avatar photos in the
> buddy list. How are people with no digital cameras supposed to get
> such a thing?
>
>     http://wiki.laptop.org/go/Image:Sugar.png
>
> Second question - the Presence DBUS service bears a strong resemblence
> to the Galago presence service. Is there some reason you're creating a
> new one?

First off, the problem with the current implementations of presence in
most everything, including Telepathy & Galago, is that they are geared
towards traditional notions of presence.  By which I mean "Is Tommy
online?  What capabilities does Tommy have?"  That's about it, as far as
I can tell from the Telepathy D-Bus API and what I've read about Galago.

In our case, we have an expanded notion of presence beyond whether or
not a buddy is simply present and whether or not they can do video chat.
In our model, each buddy provides certain services (in the mDNS/ZeroConf
sense of the word), for example a chat service or a voip service, or an
activity service.  Advertisement of an activity service determines a
person's participation on the activity.  This matches up much more
closely to Jabber/XMPP's Service Discovery specification, except that
instead of jabber servers advertising services like directories and
conference rooms, the _buddys_ are advertising their own services.  Or,
if you prefer, it's much more of a ZeroConf view, if you include
publishing.

We're not trying to combine and reconcile presence attributes from users
of different accounts and services and match that up to stored
information, which is what I understand is one of Galago's purposes.
I'd view the Sugar PresenceService as more parallel to Galago, rather
than built on top of Galago, though we likely could do that.  But I
don't see the advantage to building this on top of Galago, which is in
turn just built on top of Telepathy.

The point is that we're not just doing presence in the traditional term
of the word, like AIM, Jabber, MSN, Yahoo, etc. all think of presence.
That's a pretty simple idea of presence.  We also need to do this sort
of stuff without a central server, on the local mesh, where mDNS works
great and provides exactly the model we want.  Perhaps that could be
done with a plugin for Telepathy, but I'm not sure what the benefit of
adding Galago on top of all this is, if we're just going to have to do a
bunch of processing aside from Galago too.

Dan


Reply | Threaded
Open this post in threaded view
|

Couple of questions

Mike Hearn-3
OK cool, great answer, thanks! What about the first question? :)
Reply | Threaded
Open this post in threaded view
|

Couple of questions

David Nielsen
s?n, 23 07 2006 kl. 19:13 +0100, skrev Mike Hearn:
> OK cool, great answer, thanks! What about the first question? :)

One could imagine using a default image and hope for the respective
schools to get cameras donated, the interface appears to present no big
problems with replacing the user profile image.
We can't solve every problem but we can make it easy for the children to
adapt the laptop to their conditions, if they have access to a camera
giving them the chance to personalize their laptop is a rather neat
idea.

Just a thought.

- David Nielsen



Reply | Threaded
Open this post in threaded view
|

Couple of questions

Tom Hoffman-2
On 7/23/06, David Nielsen <[hidden email]> wrote:

> s?n, 23 07 2006 kl. 19:13 +0100, skrev Mike Hearn:
> > OK cool, great answer, thanks! What about the first question? :)
>
> One could imagine using a default image and hope for the respective
> schools to get cameras donated, the interface appears to present no big
> problems with replacing the user profile image.
> We can't solve every problem but we can make it easy for the children to
> adapt the laptop to their conditions, if they have access to a camera
> giving them the chance to personalize their laptop is a rather neat
> idea.

Or the kids could draw an avatar with a drawing application?  Or,
realistically, they'll download pictures of their favorite anime
characters, etc.

(also, I can't help pointing out that if we were talking about laptops
for the US, the problem would be how to STOP kids from using
photographs of themselves)

--Tom
Reply | Threaded
Open this post in threaded view
|

Couple of questions

Robert McQueen-2
In reply to this post by Dan Williams-4
Dan Williams wrote:
> First off, the problem with the current implementations of presence in
> most everything, including Telepathy & Galago, is that they are geared
> towards traditional notions of presence.  By which I mean "Is Tommy
> online?  What capabilities does Tommy have?"  That's about it, as far as
> I can tell from the Telepathy D-Bus API and what I've read about Galago.

Telepathy borrows heavily from Galago's ideas of presence. In both there
is the idea of your presence being a set of potentially multiple
statuses, so you can be online as well as participating in various
activities. Both Telepathy and Galago statuses are also arbitrarily
extensible using key/value arguments. I don't think it'd be hard to map
between either and the presence API.

> In our case, we have an expanded notion of presence beyond whether or
> not a buddy is simply present and whether or not they can do video chat.
> In our model, each buddy provides certain services (in the mDNS/ZeroConf
> sense of the word), for example a chat service or a voip service, or an
> activity service.  Advertisement of an activity service determines a
> person's participation on the activity.

Don't worry about this, it's very easy to imagine implementing this on
top of Telepathy, or adding an interface for it - Telepathy's design is
very extensible for exactly these reasons.

> This matches up much more
> closely to Jabber/XMPP's Service Discovery specification, except that
> instead of jabber servers advertising services like directories and
> conference rooms, the _buddys_ are advertising their own services.  Or,
> if you prefer, it's much more of a ZeroConf view, if you include
> publishing.

Service discovery results are perfectly valid on any jabber ID (be it a
room, or a server, or a contact), but are not meant to change after
being queried. What you want is much closer to entity capabilities -
these are embedded inside your <presence> node, and refer to cachable
sets of service-discoverable features, and one is able to change which
sets of features are available on the fly.

> We're not trying to combine and reconcile presence attributes from users
> of different accounts and services and match that up to stored
> information, which is what I understand is one of Galago's purposes.
...
> We also need to do this sort
> of stuff without a central server, on the local mesh, where mDNS works
> great and provides exactly the model we want.  Perhaps that could be
> done with a plugin for Telepathy, but I'm not sure what the benefit of
> adding Galago on top of all this is, if we're just going to have to do a
> bunch of processing aside from Galago too.

I don't think a bunch of processing aside from Galago will be necessary,
but what Galago does offer is the seamless coalescing of information
about buddies from a number of sources. The idea is that multiple
sources provide information (eg your address book, any IM account(s) you
have on, etc) and everyone stores or copies it to Galago's person model,
which can be queried, used and updated from anywhere else. On a desktop
deployment of Telepathy, Galago is pivotal in re-assembling the concept
of people which you lose by splitting up the backends into seperate
processes. On Sugar, if you only ever have one account on one backend
then Galago isn't necessarily a big win, so I'd agree to some extent.

> Dan

Regards,
Rob