Hi folks, We're currently in the process of designing the protocol that OLPC laptops (currently aiming at Update.2) can use to talk to a XMPP server component. Currently we do some odd things (which seemed like a good idea back in March when we had no UI for subscribing to people), such as rely on a shared roster configuration on the server that lets everyone see everyone else, and put stuff which is actually per-activity (which are magically blessed MUC rooms) into other PEP nodes which everyone pushes around. This sucks.
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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel