Peter Saint-Andre wrote: > Johannes Wagener has sent me version 0.0.4 of the IO DATA proposal: > > http://www.xmpp.org/extensions/inbox/io-data.html
I'm not sure if I understand this correctly. On | <query xmlns='http://jabber.org/protocol/disco#info' | node='get_threedimensionalcoordinates'/> the node is basically the command to execute, the function call when speaking of an API. Each function service.university.example.org supports is a node on its own, right? And to get a list of all possible commands I have to call query for disco#items. And making it even more complex, service.university.example.org could provide a lot of functions. In that case subnodes could be used. I'm thinking here of a set-top box providing support for remote playback and recording, each services with many functions. I guess that would be two nodes, each with the functions as subnode. Now my problem: XEP-0115 can't help me to discover what services are provided. I have to crawl through the complete tree to find out what functions it has. Even worse, if a service is added I will never know without re-crawling everything. Or am I thinking too complex here and IO-Data should not be used in such a scenario? The alternative would be that profiles like remote playback and recording would be used without IO-Data, maybe as XEP. Dirk -- Time flies... after you hit the snooze button.
