"All sorts of entities and services." The more pervasive Jabber becomes, and the more uses to which it is put, the larger the world of entities grows. And therein lies the challenge. How can we identify, organize and navigate these entities in any useful way? Within the relatively narrow world of IM, the entities that exist (the IM users) and the hierarchies and relationships that are formed between them (where the only hierarchies are in the form of user rosters) don't really present much of a problem; as all the entities are users, there's no classification problem, and there's no hierarchical navigation problem. But within a system that regards users, applications, and services as equals (the unifying concept of a JID is an especially powerful device here), we need to have some way of searching, traversing, discovering, and querying these entities that is consistent regardless of what those entities are. Enter Jabber Browsing.
Browsing was introduced with the 1.4 Jabber server to solve some specific problems with service discovery: how clients found out about what services (say, what IM transports) were available on the Jabber server that they were connected to. The namespace mechanism that supported this discovery (jabber:iq:agents) was found to be too restrictive, and more importantly, too specific. What was needed was a more generic way of describing entities in the Jabber world.
Browsing has since grown from that single problem space and can now be found in Jabber software everywhere. Want to find out what a user's client is capable of (so you can interact with it) or what it otherwise offers? Just browse to it. Want to find out what conference rooms currently exist on a particular conference service? Browse that service. Want to take a peek to see who's in one of the rooms? Navigate down one level to browse to the room. [1]
There are three key elements that make browsing so flexible and so powerful:
Browsing follows the MIME model in defining categories and subcategories, but rather than content being categorized (text/plain, image/png, and so on), the categorization in browsing is of of entities that can be browsed to. Categories are used to describe users, services, agents, conferencing mechanism, applications, and so on. Within these categories, the subcategories are used to make finer distinctions.
Every entity described in browsing is identifiable by a JID; the world is homogenized, so to speak. The JID is the key to browsing navigation as, when listed in a browse result as identifiation for an entity, that JID can be used as the target of the next browse request.
Browsing describes entities in the Jabber world. But the world isn't flat ... it's hierarchical! Relationships between entities are easily established and described by placing browse information in hierarchies. These hierarchies represented in XML. A typical browse response might contain descriptions of entities on one or two levels. These levels can be navigated simply by choosing the JID of the desired node and making a further browse request, creating an instant "drill-down" method of accessing information. 'drill-down'.
So, Jabber entities can be classified, given identities, organized into hierarchies, and navigated. What takes place from there is really down to the imagination. But what is a Jabber entity? For the sake of argument, let's say it's anything that has a JID. Does having a JID presume having an IM user account with a Jabber server? Not necessarily, as we'll see. So as long as we assign a JID to something we wish to include in the Jabber world, most anything goes. In the section called Browsing LDAP in Chapter 9 we build an LDAP 'reflector' service that enables us to browse LDAP information from within our Jabber clients.
Browsing is a combination—a culmination even—of many of the Jabber features. Browsing is carried out in the context of the IQ request/response mechanism, and uses a namespace-qualified payload to carry the data whose hierarchy is naturally expressed in XML. And it bridges, philosophically and technically, the distances between the Jabber and non-Jabber spaces.
| [1] | If this is permitted by the room. |