anders conbere wrote: > Are all the users on the same network? Not necessarily, no.
> are you looking for support of arbitrary activities? Yes, we're acting as a transport for arbitrary unknown activities. > if so Is it not possible to just dynamically create MUC's based on the > activity name chosen? Instances of activites are given a unique hash identifier which is used to name the MUC room they use. This doesn't help us though, because there can be more than one instance of a given activity (different grups of people editing different documents). > I mean you're kind of in a bind when it comes to discoverability and > the current protocol, but you might look at something like supporting > bonjour and having the laptops broadcast the JID of the logged in > user, this might be as viable as your current solution but doesn't > depend on a shared roster to find everyone around you. From there if > your client supported auto-confirmations then you could fairly > seamlessly chat with everyone in your area. We have two Telepathy (http://telepathy.freedesktop.org/) backends in use on the device, one is telepathy-gabble for this XMPP-based collaboration, and one is telepathy-salut which uses XEP-0174 link-local XMPP. This uses mDNS to find buddies, TCP connections for direct communication, and we've also extended it with a reliable multicast protocol to allow link-local group chat and collaboration. In this case we do use mDNS records to allow other laptops to enumerate the publically shared activities they can join. Unfortunately, as we want to be able to use the XMPP server to collaborate with people who aren't on the local network segment, this doesn't really help us with the server case. > Anyway, I'm curious. > > ~ Anders Regards, Rob >> Some relevant background information: >> * The protocols we use to implement shared activities: >> http://wiki.laptop.org/go/Shared_Activity_Protocol_1.0 >> * The XMPP extensions we rely on (and how we (ab?)use them): >> http://wiki.laptop.org/go/XMPP_Extensions >> * The server configuration we require: >> http://wiki.laptop.org/go/Ejabberd_Configuration >> http://wiki.laptop.org/go/Openfire_Configuration (this is still a bit >> experimental and needs a couple of patches to our client code to take >> care of slightly different MUC/PEP semantic - we started with Ejabberd >> because it had a PEP patch available back in March) >> >> The goals of our component are the following: >> * it can be easily deployed without needing anything more specific than >> a Jabber server that has support for PEP and MUC >> * it doesn't rely on any abnormal configuration/behaviour on the Jabber >> server that breach the normal XMPP approaches to privacy >> * it doesn't rely on being able to access information from the server's >> MUC or PEP implementations in any non-standard mechanisms >> * it can scale better than the current protocol, possibly even to >> 50,000 laptops if we consider the G1G1 (http://www.laptopgiving.org/) >> programme, and a suitably scalable server >> * it adds the ability to do server-side searching which we currently >> lack, except by dint of the fact that we currently see everything so we >> can implement filtering on the client side >> >> The component protocol we're designing to address these goals is >> documented here: >> http://wiki.laptop.org/go/XMPP_Component_Protocol >> >> The general idea is that we keep using PEP for the per-buddy information >> (the OLPC buddy properties, and the current activity) so we receive that >> for our buddies, but we stop using it for any activity information and >> we use extended MUC invites and change messages inside the MUCs to send >> the activity properties around. The component then uses both of these >> technologies (you subscribe to the component so it can see your PEP >> notifications, and you invite it into activity MUCs you want to publish) >> to make the buddy property, activity property and activity membership >> information searchable for people who aren't on your roster, and push >> updates to them. >> >> (For the people on the XMPP standards list, I should probably point out >> that I'm not particularly proposing any of this to be standardised, I'm >> just looking for any feedback or input on our design, and what concerns >> will impact its scalability.) >> >> One particular unsolved issue we have is that because the component >> doesn't know who your friends are, this means that we will find out >> about activities from our friends' PEP nodes which we don't have the >> activity properties for. Currently this means when we encounter an >> activity that's not in our current result set, we'll have to manipulate >> this (or another set) of our friends's activities which we'd like to >> also receive the properties for. Ideally the component would already >> know, and could push these details to us. Any suggestions on how to >> address this are welcome. >> >> On a related note, it seems that there is the possibility that we want >> to change the protocol so we can open up a few distinct sets of results, >> such as certain activities or buddies, and have the server keep them >> around so it can keep pushing us notifications when anything changes. >> Should we be using something different to Result Set Management given >> that says it's aimed at stateless queries, or do you think it's ok to >> re-use it once we've worked out how to open/close different search contexts? >> >> And generally, what do people think? Is there a completely different >> approach we should be taking? Thanks for your time... apologies for the >> over-long e-mail too. :) >> >> Regards, >> Rob >> >> >
