This approach might be easier: - Create a PEP node called Activies. - When an activity is launched, publish this:
<activity id="activity_id" start="timestamp">Drawing</activity> - When an activity is closed, publish this: <activity id="activity_id" end="timestamp">Drawing</activity> This is totally compatible with ISS. Other nodes may exist with no problems. On Dec 5, 2007 3:08 PM, Nick Vidal <[EMAIL PROTECTED]> wrote: > Hi Robert, > > I'll have to review your wiki to give you a better feedback. > > As for now, you might be interested in looking at: > > http://iss.im/node/49 > http://iss.im/ > > I added a description here: > > http://wiki.laptop.org/index.php?title=OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Zoom_Metaphor&diff=next&oldid=68603 > > > While your work uses PEP to keep children aware of friends' activities, > ISS uses PEP to keep children aware of friends' projects and ideas (based on > tags used on their journal). > > Best regards, > Nick > > > On Dec 5, 2007 2:45 PM, Robert McQueen <[EMAIL PROTECTED]> > wrote: > > > 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 > > > > >
