On Wed Sep 22 08:56:01 2010, Michael McCarthy wrote:
Basic Service Discovery (0030) - In order to retrieve full
information about an entity and its associated items, the
requesting application needs to "walk the tree" of items.
Naturally, this can result in a large number of requests and
responses. The requesting application SHOULD NOT send follow-up
requests to all items associated with an entity if the list of such
items is long (e.g., more than twenty items).
Problem - There will likely be more than 20 rooms to query
individually.
Well, nothing prevents you from asking each room - that's strong
advice, but you have good reason to ignore it. However, I agree it's
not ideal.
Extended Service Discovery (0128) - An entity MUST NOT supply
extended information about associated children communicated via the
'http://jabber.org/protocol/disco#items' namespace, since a core
principle of Service Discovery is that an entity must define its
own identity only and must not define the identity of any children
associated with the entity.
Problem - As the entity being queried here (I imagine) is the MUC
service itself, am I breaking protocol by asking for a lot of
information about it's children?
Yes. :-)
Jabber search doesn't seem quite right as it doesn't feel like a
search - I always query for the same information so service
discovery seems the natural fit.
No, I think XEP-0055 with forms is the way to go, here - you're then
allowed to return basically whatever information you want to the
client. I've been thinking of adding a search to our MUC service,
actually.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
