[Standards-JIG] Presence Based Features (was: Registering Translation)

Chris Mullins chris.mullins at coversant.net
Tue Oct 10 20:31:10 UTC 2006


Jean-Louis Seguineau Wrote:
> That said, wouldn't we be better off separating 
> discovery (i.e. is the service supported) from
> availability (i.e. is the service present). 

I would like to see them seperated, but mostly due to discovery storms
on login. The way most clients work now is that they ask the server for
all items, and then recursibly query all of the items. This creates a
huge (and often un-necessary) load on login. 

> Of course, it may imply a slight modification of 
> the way the client lookup the translator service 
> by using disco and then probing the bot presence. 
> But is that really unrealistic?  

The way things sit now, any translation bots that come online all show
up in the Disco Items for the server. I could easily see this list being
huge on the some servers - this huge list would in turn cause the disco
storm issues and should be avoided. 

What's interesting is that this JEP doesn't really have any server side
component, so there's nothing a server needs to do. It's all about
adding presence enabled services through bots. 

> More generally, I believe your initial question 
> highlight a typical case that will inevitably 
> become more frequent as "presence enabled" 
> services multiply.

I agree - I think this will start to show up more often. Many of these
services will also be paid services (per message, per transaction, per
minute, etc) and offering their features through bots of some sort seems
like an excellent way to go. 

> Everything considered, your suggestion of an 
> extension of the XEP to include a presence 
> related discovery might become main stream 
> sooner than you think ;)

I would be all for this. There would be a few requirements:

1 - There needs to be a way to not query for the features unless it's
something you're specifically interested in. The current disco mechanism
used by clients invites too much network traffic in the general case. 

2 - There needs to be a way to load-balance amoung bots performing
identical features. Essentially this should mirror the way DNS lookups
work, with a feature lookup returning a random bot. This way services
can be seamlessly scaled without any fancy hardware or software.

3 - The server should be able to provide a list of the features that are
available "right now". This could be part of the standard disco request.
Once a client determines they're interested in a feature (say,
Translation) they could query the server for more information. 

4 - A security mechanism to prevent everyone and their brother from
feature spamming the server. There are a number of options here...

> More generally, I believe your initial question 
> highlight a typical case that will inevitably 
> become more frequent as "presence enabled" 
> services multiply.

I agree. I would love to see an entire XMPP ecosystem develop of people
offering services this way. There are plenty of services that could be
done. This is something the closed networks really don't easily allow. 

For example, think of the fun:
1 - Dating Services
2 - Shared Calendaring Services
3 - Translation
4 - Horoscopes
5 - Sports Betting / Odds Making (offshore, of course!)

These are all cases where presence / roster subscriptions don't really
fit. These are also cases where we don't really want to require server
components to be written. It's much easier to have these be standard
clients that just log into a server and register features. 

I certainly don't want to send a horoscope provider my presence, or have
them send me theirs. Nor do I want them taking up space in my roster. If
nothing else, both are wastes of bandwidth in our increasinly mobile
protocol. 

I would, however, be happy to have a tab (similar to MSN) for a
horoscope and to be able to pick from different service providers. 

-- 
Chris Mullins




More information about the Standards mailing list