[Server-devel] Gadget fedora package

[Robert McQueen]

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
activities.

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.

> cheers,
> 
> martin

Regards,
Rob

-- 
Robert McQueen                                 +44 7876 562 564
Director, Collabora Ltd.             http://www.collabora.co.uk