[Standards] Service discovery for clients
stpeter at stpeter.im
Tue Jul 1 22:15:35 UTC 2008
> Maciek Niedzielski;1340 Wrote:
>> If I remember well, pubsub (xep60 pubsub, not pep) delivers events as
>> messages sent to _bare_ jid just after event occurs. So pubsub
>> server/service cannot check client features because it doesn't know
>> where the message will be routed. It may even end up in offline
>> And it's hard to improve this situation because pubsub service doesn't
>> know your presence, so it doesn't know where to ask about supported
The pubsub service *might* know your presence, but it might not. Perhaps
in deployment, smart pubsub services will decide that they really need
presence (from which they'll get caps/disco) and the problem will be solved.
> Of course. That's why I am not speaking about the pubsub service, but
> about your server which routes your messages. The best way is to route
> the right message to the right client. Or else the only future for
> multi-feature XMPP is either to have as many JID as you use different
> feature or to have a single client which can do absolutely everything.
> But the fact is that many people prefer to have different clients for
> different feature. Or sometimes you can only use some basic client (as a
> limited web client while at work when the network ports are restricted
> but still want to get all your unsupported messages the evening when
> arriving home with your full-featured client). Etc.
Resource Application Priority (XEP-0168) was intended to solve something
like this problem, but perhaps it needs to be updated or reworked -- I
have not looked at it in a while.
More information about the Standards