[Server-devel] Gadget fedora package
robert.mcqueen at collabora.co.uk
Thu Dec 11 13:34:04 EST 2008
Martin Langhoff wrote:
> But I'm working on this space at the moment - switching away from the
> "all online users" patch that I suspect Guillaume is talking about and
> shifting to a different strategy using PostgreSQL.
> So its "mostly behind us" (emphasis on mostly) as I mentioned but
> things are looking promising. The strategies I'm planning to use are
> in use by several large scale sites based on ejabberd with custom
> roster behaviours.
I thought about having the server subdivide people into smaller mutually
visible groups, particularly in G1G1 when having magic groups which try
and group by network proximity or random grouping is reasonable. It
works just because that the n^2 scalability problems are avoided by
simply making n smaller, but I still believe that approaches based
around shared rosters aren't ultimately the right thing to do.
Remember that what we're talking about isn't simply whether people can
see each other's presence or not, but that we rely on a bidirectional
presence subscription to use PEP to publish the extra OLPC-specific
properties of a buddy, as well as their currently active activity, all
of the activities they're running, and the properties of all of those
Problems with this:
* It's further from what XMPP does normally because it continues and
presumes/presupposes that the server knows best who should see each
other. Gadget only publishes buddy information if they subscribe to
it, and only publishes activities if it's invited to it, allowing
fine-grained control, and for the other cases we should allow people
to punch in JIDs or find people in activities/groups and make their
own friendship subscriptions.
* It's inefficient because every client in an activity ends up pushing
PEP nodes with verbose details of their activities, when actually if
the server had a concept of the activity it would only need to be
aware of one copy of this information. That means when an activity
changes its properties, you get the changed activity details N times,
once for each participant. Gadget receives the activity details
directly from the activity once only.
* It's inefficient because the server pushes all of these to all
clients in the mutually-visible group, even if that's too much
information for the UI to display, or it's just not relevant because
that view isn't open currently. Gadget pushes changes to only those
people who are interested in a certain activity.
* It precludes finer-grained visibility controls - you can't set up
activities which are only visibile to certain groups of people
without letting those people see all of your activities, or none.
Although Gadget currently allows all people on a server to query an
activity it's invited to, it gives us one place to implement
functionality like sharing with certain groups or list of people.
* You're limited to having subsets of people who are on one server, and
because we need bi-directional subscriptions for PEP to work, both
servers need to agree, so you really have very few options for
including other people from other servers unless you start setting up
a protocol by which servers inter-agree who should see each other on
users' behalves. Seems pretty tricky...
Further to this Gadget offers:
* Searches for buddies and activities are made out of all information
available to Gadget, rather than people being split into different
"silos". So even if people in different classes are using some niche
activity, they can still find each other.
* If server to server connections are enabled, its possible to invite a
Gadget from another server (a partner school, for example) into an
activity to make it searchable by people in the other school. We
could even look at gadget<->gadget propogation of activities and
buddies if we wanted to.
Robert McQueen +44 7876 562 564
Director, Collabora Ltd. http://www.collabora.co.uk
More information about the Server-devel