Een paar bugs met disco#items
Thijs Alkemade
Ik kwam dit project tegen op de XMPP summit mailing list, en vond het
een heel erg cool idee!
Ik begrijp dat het bedoeld is als een API (en dan vooral bedoeld voor
pubsub), en niet iets wat je direct hoort te gebruiken, maar toch nam
ik een kijkje met Adium's Discovery Browser (wat niet meer is dan een
interface om door XEP-0030 te bladeren) en liep tegen een paar bugs
aan.
- Als ik de disco#items opvraag van de node "stations", krijg ik een
lijst terug met alle stations, maar die hebben allemaal een node die
niet klopt:
<iq xmlns='jabber:client' type='result' from='nsapi.xmpp.openov.nl'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='stations'>
...
<item jid='nsapi.xmpp.openov.nl' name='Utrecht' node='ut'/>
...
Om meer informatie over Utrecht te krijgen, moet ik 'stations/ut'
opvragen, maar de node staat hier als enkel 'ut'.
- Niet alle queries (bijvoorbeeld voor disco#items op 'stations/ut/
avt') bevatten de node waar de query voor was:
Ik stuur:
<iq type='get' to='nsapi.xmpp.openov.nl>
<query xmlns='http://jabber.org/protocol/disco#items' node='stations/
ut/avt'/>
</iq>
Ik krijg:
<iq xmlns='jabber:client' type='result' from='nsapi.xmpp.openov.nl'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='nsapi.xmpp.openov.nl' name='13:43 Intercity richting
Schiphol' node='stations/ut/avt/3548'/>
...
Ik durf niet helemaal te claimen dat het verplicht is, maar examples
19 en 21 van http://xmpp.org/extensions/xep-0030.html#items-nodes laat
zien dat het <query> element van het resultaat een 'node' attribuut
heeft als de query voor een specifieke node was. Adium raakt in ieder
geval in de war als dat attribuut mist (het blijft wachten op een
antwoord).
- En als laatste (weet niet of het een bug is, of dat de API zo
bedoeld is), de root node geeft item-not-found terug voor disco#items,
ipv 'stations' en 'treinen'.
Groet,
Thijs
Stefan de Konink
> Ik begrijp dat het bedoeld is als een API (en dan vooral bedoeld voor
> pubsub), en niet iets wat je direct hoort te gebruiken, maar toch nam
> ik een kijkje met Adium's Discovery Browser (wat niet meer is dan een
> interface om door XEP-0030 te bladeren) en liep tegen een paar bugs
> aan.
Je mag het natuurlijk gebruiken :) <http://nsapi.xmpp.openov.nl/> kun je
ook een beetje mee kijken (/ en zonder / op nodes voor service-discovery
versus getitems).
> - Als ik de disco#items opvraag van de node "stations", krijg ik een
> lijst terug met alle stations, maar die hebben allemaal een node die
> niet klopt:
>
> <iq xmlns='jabber:client' type='result' from='nsapi.xmpp.openov.nl'>
> <query xmlns='http://jabber.org/protocol/disco#items'
> node='stations'>
> ...
> <item jid='nsapi.xmpp.openov.nl' name='Utrecht' node='ut'/>
> ...
>
> Om meer informatie over Utrecht te krijgen, moet ik 'stations/ut'
> opvragen, maar de node staat hier als enkel 'ut'.
Bedankt, net gefixed!
> - Niet alle queries (bijvoorbeeld voor disco#items op 'stations/ut/
> avt') bevatten de node waar de query voor was:
>
> Ik stuur:
>
> <iq type='get' to='nsapi.xmpp.openov.nl>
> <query xmlns='http://jabber.org/protocol/disco#items' node='stations/
> ut/avt'/>
> </iq>
>
> Ik krijg:
>
> <iq xmlns='jabber:client' type='result' from='nsapi.xmpp.openov.nl'>
> <query xmlns='http://jabber.org/protocol/disco#items'>
> <item jid='nsapi.xmpp.openov.nl' name='13:43 Intercity richting
> Schiphol' node='stations/ut/avt/3548'/>
> ...
>
> Ik durf niet helemaal te claimen dat het verplicht is, maar examples
> 19 en 21 van http://xmpp.org/extensions/xep-0030.html#items-nodes laat
> zien dat het <query> element van het resultaat een 'node' attribuut
> heeft als de query voor een specifieke node was. Adium raakt in ieder
> geval in de war als dat attribuut mist (het blijft wachten op een
> antwoord).
Ik denk dat hij op z'n plaat gaat omdat hij niet zo slim is om een id mee
te zenden in z'n query. Als hij dat wel had gedaan dan had hij de id
kunnen relateren aan zijn vraag. Dus feitelijk lijkt me dit een bug in
Adium, omdat ik ook de beroerdste niet ben, heb ik hem er even aan
gehangen ;)
> - En als laatste (weet niet of het een bug is, of dat de API zo
> bedoeld is), de root node geeft item-not-found terug voor disco#items,
> ipv 'stations' en 'treinen'.
Deze is 'mogelijk' gefixed. Heb dat alleen nog niet zelf kunnen
controleren.
Heel erg bedankt dat je er zo inhoudelijk naar hebt gekeken :)
Stefan
Thijs Alkemade
On Jan 11, 3:30 pm, Stefan de Konink <ste...@konink.de> wrote:
>
> Ik denk dat hij op z'n plaat gaat omdat hij niet zo slim is om een id mee
> te zenden in z'n query. Als hij dat wel had gedaan dan had hij de id
> kunnen relateren aan zijn vraag. Dus feitelijk lijkt me dit een bug in
> Adium, omdat ik ook de beroerdste niet ben, heb ik hem er even aan
> gehangen ;)
weggelaten om het te verduidelijken. Ik weet dat deze verplicht zijn
op iq's, maar het klopt dat Adium niet de id's vergelijkt, maar alleen
kijkt naar de node van de <query>. Toch bedankt voor het fixen!
>
> > - En als laatste (weet niet of het een bug is, of dat de API zo
> > bedoeld is), de root node geeft item-not-found terug voor disco#items,
> > ipv 'stations' en 'treinen'.
>
> Deze is 'mogelijk' gefixed. Heb dat alleen nog niet zelf kunnen
> controleren.
>
<iq type='get' to='nsapi.xmpp.openov.nl' id='AMPurpleJabberNode961,'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
<iq xmlns='jabber:client' id='AMPurpleJabberNode961,' type='error'
to='...' from='nsapi.xmpp.openov.nl'>
<error xmlns='jabber:client' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Ook zie ik nu dat het lijkt het alsof ik voor 'stations/.../storingen/
gepland' en 'stations/.../storingen/actueel' via disco#items altijd
item-not-found terug krijg, hoewel het over pubsub wel items bevat.
Hoort dit?
Thijs
Stefan de Konink
> Ook zie ik nu dat het lijkt het alsof ik voor 'stations/.../storingen/
> gepland' en 'stations/.../storingen/actueel' via disco#items altijd
> item-not-found terug krijg, hoewel het over pubsub wel items bevat.
> Hoort dit?
Dat klopt denk ik wel, storingen is een vage situatie.
Stefan