[Standards] Re: XEP-0073: Question about service discovery

Robin Redeker elmex at x-paste.de
Thu Feb 8 17:05:32 UTC 2007


On Thu, Feb 08, 2007 at 04:57:37PM +0100, Remko Tronçon wrote:
> >> Adding a caps for OS seems to be somewhat overkill for such a simple
> >> problem, to me.
> >
> >I think the OS is a fine candidate for disco meta data. It is not a
> >capability.
> 
> jabber:iq:version, disco meta data (don't even know what that is ;-),
> extended presence (PEP), fine, but i'm also with Kev and ralph that
> these aren't capability related. It should only be presented upon
> request, it is too specific for general use.

Yay, then I will simply send a request for the OS to each of my contacts
when I or the contact logs in! And back is the flooding :-)
Or am i wrong?
I'm also not voting for OS information being a 'capability' but
delivering this information only on request will lead to client
behaviour that we already have. Or at least it won't lead away from
that behaviour.

Or at least the spec for that OS 'disco meta data' should clearly
say that the client should only request the information when a user
wants it. But this is a rather blurry recommendation. If i want
my client to display the users OS with a small icon next to his name
(a tux or a windows flag, whatever ...) the client will certainly
request the data upon each login.

The amount of redundant data is maybe limited, but it should be
examined whether it is acceptable.

Just my random thoughts:

I would maybe attach some key or id to the presence information sent
by a user which could be used as cache-key. And when the key changes
I know that his disco information has changed. Something like this:

   <presence>
     <c xmlns='http://jabber.org/protocol/caps'
        node='http://exodus.jabberstudio.org/caps'
        ver='0.9'
        discoid='61e9c30111188a497a3ec7c6cc0d6543'/>
   </presence>

(Note: whether the discoid attribute is on the <c> tag or some other special
tag doesn't matter. This is just an example.)

The client receives this presence and does following requests, as usual:

   <iq type='get' to='randomuser1 at capulet.com/resource'>
     <query xmlns='http://jabber.org/protocol/disco#info'
            node='http://exodus.jabberstudio.org/caps#0.9'/>
   </iq>

Along with a simple disco#info for the other disco information:

   <iq type='get'
       to='randomuser1 at capulet.com/resource'
       id='info1'>
     <query xmlns='http://jabber.org/protocol/disco#info'/>
   </iq>

The reply to the last request then could look like:

   <iq type='result'
       from='randomuser1 at capulet.com/resource'
       to='juliet at capulet.com/balcony'
       id='info1'>
     <query xmlns='http://jabber.org/protocol/disco#info'>
       <foo discoid='61e9c30111188a497a3ec7c6cc0d6543'/>
       <identity
           category='client'
           type='pc'
           name='Gabber'/>
       <feature var='jabber:iq:time'/>
       <feature var='jabber:iq:version'/>
     </query>
   </iq>

The <foo> tag is just an example place for the discoid. It's just important
that the disco information comes along with a key that changes when the
information changes. It could be a md5sum over something, it doesn't really
matter, as long as it allows the requesting client to cache the disco
information and only re-requests it when it changes (which he will notice by
the discoid attribute in the anotated presence stanza).

This mechanism is a bit more generic than the approach that XEP-0115 does
and would also allow caching of this 'disco meta data'.

But maybe OS information could also be some kind of subscribable information.
This kind of caching could also be extended to other XEPs. For example the vcard
mechanism...
As far as I can see caching of the vcard information obtained via the protocol
described in XEP-0054 does not allow any caching: If the user asks the client
10 times to give me the vcard of elmex at example.com, the client will everytime
have to send a request and wait for the vcard (if it doesn't it risks displaying
outdated or invalid information).

But these were just some random thoughts...


Robin



More information about the Standards mailing list