[standards-jig] Checking for implementations

David Waite mass at akuma.org
Wed Apr 17 04:58:07 UTC 2002

Adam Theo wrote:

> What do you not like about browse, specifically? Or are there posts in 
> the archives which sum up your thoughts nicely?

It exposes a directory-style interface, but the information of children 
(address, name, type, namespaces supported) is reported by the parent, 
and not by the children themselves. In something like LDAP this is fine 
because the children are part of the same data store as the parent; its 
just the format of the query. In a distributed system like Jabber this 
has issues.

There is no search mechanism, or way to limit results. When 
irc-transport added support for browse, going to it did a '/list' of all 
rooms on the server being pointed to. It was pointing to efnet, so that 
that was about 46,000 rooms, or around a 8MB response.

There is introspection built in by namespace/protocol lookup - it 
assumes a 1 to 1 mapping of desired feature to namespace support. This 
has been called feature-negotiation, but there is no built-in way to do 
true feature negotiation, such as indicating a choice of acceptable 
options with a preferred order. There is also no way to say you just 
want to get available namespaces supported; to find out which 
conferencing protocols irc-transport supported, I had to retrieve the 
room list.

There is only one axis for children - I might want to have a 
conferencing server contain rooms and a room to contain people, but that 
conferencing server might also have a separate heirarchial 
representation of rooms (so you can have categories and subcategories of 
topics), such as on yahoo. The session manager might expose both the 
services known to it, as well as a list of all available users on the 

There is no way to defined way to attach additional data to an entry 
within browse; for instance, I might want to have a filesystem browser, 
and have the major and minor mimetypes ,size of the files, and 
creation/modifcation time exposed to the browsing client. It may be 
acceptable to have this exposed via a separate namespace, but that would 
cause one extra request/response per item returned in the browse. I'd 
prefer actually if all the existing category-style information was 
exposed in this manner, so that it was optional and could be replaced.

It has elements of pub/sub - you subscribe to a topic by sending 
presence then requesting browse information, at which points you are 
supposed to get changes in the tree as long as you are available (a 
non-durable subscription). There are also elements of the data retrieval 
cases which may or may not be part of pub/sub. If we were proposing a 
new protocol, I'd prefer this to use whatever pub/sub stuff we agree on.

Now, the advantage of the existing protocol is that having all of the 
concepts rolled together in browse is that a very specific request gets 
all the needed response data back. Breaking things apart means that 
getting the required data could become significantly more 
resource-intensive and complicated.

-David Waite

More information about the Standards mailing list