📄 x5334.htm
字号:
(AIM transport), and <TT
CLASS="LITERAL"
>jud</TT
> (Jabber User Directory).</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
>user</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Various addressable elements of users, such as their clients (subtype
<TT
CLASS="LITERAL"
>client</TT
>), inbox mechanisms (subtype
<TT
CLASS="LITERAL"
>inbox</TT
>) and so on, find themselves in this category.</TD
></TR
></TBODY
></TABLE
></DIV
><P
>The categories listed in <A
HREF="x5334.htm#JABTDG-CH-5-TAB-5"
>Table 5a-1</A
> are not
exhaustive; the <TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> namespace and the
browsing idea was introduced with version 1.4 of the Jabber server and
is still evolving. The same goes for the category subtypes.</P
><P
>Any particular browsable entity can be described using the combination
of the category and subtype. For example, <TT
CLASS="LITERAL"
>user/client</TT
>
can be used much in the same way as MIME-types. Following the MIME meme
further, we can define our own subtypes on the fly and specify them
with an <TT
CLASS="LITERAL"
>x-</TT
> prefix, such as <TT
CLASS="LITERAL"
>user/x-schedule</TT
>.</P
><P
>Indeed, the browsing description model of category/subtype follows the
MIME model; in places the category is often referred to in Jabber
documentation as the <I
CLASS="EMPHASIS"
>JID-type</I
>. The JID is critical to browsing;
it is a required attribute of all entities described in a
<TT
CLASS="LITERAL"
>jabber:iq:browse</TT
>-based hierarchy. The JID is the key
to navigating the hierarchy structure.</P
><P
>Earlier in this section we saw the results of making a query in the
<TT
CLASS="LITERAL"
>jabber:iq:agents</TT
> namespace to retrieve information
on the services available on a Jabber server. Now let's have a look at the
a similar query using the <TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> namespace:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq type='get' to='yak'>
<query xmlns='jabber:iq:browse'/>
</iq>
RECV: <iq type='result' to='dj@yak/home' from='yak'>
<service name='Jabber Server' type='jabber'
xmlns='jabber:iq:browse' jid='yak'>
<conference name='yak Conferencing'
type='public' jid='conference.yak'/>
<service name='yak User Directory' type='jud' jid='jud.yak'>
<ns>jabber:iq:search</ns>
<ns>jabber:iq:register</ns>
</service>
<service name='User Directory (Browsable)'
type='jud' jid='jud.merlix/users'/>
</service>
</iq></PRE
></P
><P
>Notice how the information returned forms a hierarchy. The outermost
item in the browse results represents the Jabber server as a whole
(with the JID <TT
CLASS="LITERAL"
>yak</TT
>) and contains subitems that
are services of that Jabber server (the <TT
CLASS="LITERAL"
>yak Conferencing</TT
> service,
and the two forms of the JUD).</P
><P
>How many levels of hierarchy can we expect to receive (as a browsing
information consumer) or provide (as a browsing information provider) in
any given situation? It really depends on the application situation.
and the balance you want to achieve
between shallow hierarchy responses and many IQ calls for navigational
descent (light extensions but more traffic)
and deeper hierarchy responses and few IQ calls for navigational descent
(heavier extensions but less traffic).</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-5A-SECT-2.5.1"
>Descending the browse hierarchy from an LDAP reflector</A
></H3
><P
>As illustration, let's have a look how we might perform a hierarchy descent
in the
navigation of LDAP information provided by a custom LDAP reflector
in a <TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> context. Each time, the link
to the next level is via the item's JID, which is the target of the
browse query.</P
><P
>First, we send an initial query:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq type="get" id="browser_JCOM_15" to="ldap.yak">
<query xmlns="jabber:iq:browse"></query>
</iq></PRE
></P
><P
>In answer to the initial query to what is effectively the LDAP root
represented by the JID of the LDAP component itself (<TT
CLASS="LITERAL"
>ldap.yak</TT
>, no
username prefix), the initial hierarchy level containing
<I
CLASS="EMPHASIS"
>People</I
> and <I
CLASS="EMPHASIS"
>Groups</I
> is returned,
wrapped in a pseudo root:</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq type='result' to='dj@yak/winjab' from='ldap.yak' id='browser_JCOM_15'>
<item name='root entry' xmlns='jabber:iq:browse' jid='ldap.yak'>
<item name='ou=People' jid='ou=People@ldap.yak'/>
<item name='ou=Groups' jid='ou=Groups@ldap.yak'/>
</item>
</iq></PRE
></P
><P
>We see the items presented to us and choose to descend the path marked
<I
CLASS="EMPHASIS"
>Groups</I
>; our second browse request is made to the JID that represents
that item, <TT
CLASS="LITERAL"
>ou=Groups@ldap.yak</TT
>.</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq type="get" id="browser_JCOM_17" to="ou=People@ldap.yak">
<query xmlns="jabber:iq:browse"></query>
</iq></PRE
></P
><P
>The LDAP reflector component receives the IQ packet addressed to the JID
<TT
CLASS="LITERAL"
>ou=People@ldap.yak</TT
> and interprets the username part of
the JID (<TT
CLASS="LITERAL"
>ou=People</TT
>) as an LDAP RDN (<I
CLASS="EMPHASIS"
>relative distinguished
name</I
>, a form of key within an LDAP structure that's further qualified by
a common suffix), which returns the appropriate information from the next
level in the LDAP hierarchy: the countries.</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq type='result' to='dj@yak/winjab' from='ou=People@ldap.yak'
id='browser_JCOM_17'>
<item name='ou=People' xmlns='jabber:iq:browse'
jid='ou=People@ldap.yak'>
<item name='ou=UK' jid='ou=UK,ou=People@ldap.yak'/>
<item name='ou=France' jid='ou=France,ou=People@ldap.yak'/>
<item name='ou=Germany' jid='ou=Germany,ou=People@ldap.yak'/>
</item>
</iq></PRE
></P
><P
>And so the descent continues, via the JID
<TT
CLASS="LITERAL"
>ou=UK,ou=People@ldap.yak</TT
> that was specified as the
unique identifier for that item (the country <TT
CLASS="LITERAL"
>UK</TT
>).</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq type="get" id="browser_JCOM_18" to="ou=UK,ou=People@ldap.yak">
<query xmlns="jabber:iq:browse"></query>
</iq></PRE
></P
><P
>which continues:</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq type='result' to='dj@yak/winjab' from='ou=UK,ou=People@ldap.yak'
id='browser_JCOM_18'>
<item name='ou=UK,ou=People' xmlns='jabber:iq:browse'
jid='ou=UK,ou=People@ldap.yak'>
<user name='cn=JanetAbrams' jid='JanetAbrams@yak'/>
<user name='cn=PaulAnthill' jid='PaulAnthill@yak'/>
...
</item>
</iq></PRE
></P
><P
>The section of the actual LDAP hierarchy browsed is shown in
<A
HREF="x5334.htm#JABTDG-CH-5-FIG-6"
>Figure 5a-1</A
>.</P
><DIV
CLASS="FIGURE"
><A
NAME="JABTDG-CH-5-FIG-6"
></A
><P
><B
>Figure 5a-1. The LDAP hierarchy browsed in <A
HREF="x5334.htm#JABTDG-CH-5A-SECT-2.5.1"
>the section called <I
>Descending the browse hierarchy from an LDAP reflector</I
></A
></B
></P
><PRE
CLASS="SCREEN"
> +--------+ -+
| LDAP | |
| | |
+--------+ |
| |
| | first
+------------------+ | query
| | | result
| | |
+--------+ +--------+ | -+
| People | | Groups | | |
| | | | | |
+--------+ +--------+ -+ |
| |
| | second
+------------------+------------------+ | query
| | | | result
| | | |
+---------+ +--------+ +---------+ | -+
| Germany | | France | | UK | | |
| | | | | | | |
+---------+ +--------+ +---------+ -+ |
| |
| | third
+---------------------+ | query
| | | result
| | |
+--------+ +---------+ |
| Janet | | Paul | |
| Abrams | | Anthill | |
+--------+ +---------+ -+ </PRE
></DIV
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN5637"
></A
></H2
><P
>Browse data isn't just something that can be retrieved; like
presence, it can be pushed to an entity when required. In the same way
that an alert in the form of a <TT
CLASS="LITERAL"
><message/></TT
>
element might arrive at a client unannounced, so might browse information
also appear. This is referred to as <I
CLASS="EMPHASIS"
>live browsing</I
>, as the information that is
pushed is effectively <I
CLASS="EMPHASIS"
>live</I
>.</P
><P
>The Conferencing service uses this mechanism
to push information on room participants to a new joiner. As the browse
information is enveloped in an IQ element, it makes the most sense to use
a <TT
CLASS="LITERAL"
>type='set'</TT
> (it might help to consider the parallel
with the HTTP verb 'POST' as introduced in <A
HREF="c445.htm"
>Chapter 2</A
>)
to push this information. And this is what happens, as seen in this excerpt
from information sent to a client as a conference room is joined:</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq type='set' to='qmacro@jabber.org/winjab'
from='jdev@conference.jabber.org'>
<conference xmlns='jabber:iq:browse' name='Development Room'
type='public'>
<user name='piers'
jid='jdev@conference.jabber.org/445d4b864bd6988b52c5244e7aa50536125e373a'/>
<user name='pgmillard'
jid='jdev@conference.jabber.org/1cffcbf43c75a007677246edc4c6f8d8c5e65b46'/>
<user name='reatmon'
jid='jdev@conference.jabber.org/b3f3c19859de4d25c1362711b81e42e36c417309'/>
...
</conference>
</iq></PRE
></P
><P
>An example of a simple <TT
CLASS="LITERAL"
>jabber:iq:browse</TT
> implementation
can be found in <A
HREF="x9016.htm"
>the section called <I
>RSS punter</I
> in Chapter 8</A
>.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5A-SECT-2.6"
><TT
CLASS="LITERAL"
>jabber:iq:conference</TT
></A
></H2
><P
>The conferencing service provides facilities for entities to join rooms
and chat to each other. The entry negotiations that take
place between a room (via the service) and a potential participant are
made using the <TT
CLASS="LITERAL"
>jabber:iq:conference</TT
> namespace. With
this namespace, information on rooms can be requested, and attempts to
enter rooms can be made.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-5A-SECT-2.6.1"
>The <TT
CLASS="LITERAL"
>jabber:iq:conference</TT
> namespace at work</A
></H3
><P
>Here we see a typical sequence of IQ elements
that ensue in the entry negotiations for the JDEV room hosted by the
conferencing service on <TT
CLASS="LITERAL"
>jabber.org</TT
>'s Jabber server.</P
><P
>Information on the JDEV room is requested:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq type="get" id="c2" to="jdev@conference.jabber.org">
<query xmlns="jabber:iq:conference"/>
</iq></PRE
></P
><P
>The conferencing service replies with the relevant information.</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>: </B
>The JID to which the query was sent—<TT
CLASS="LITERAL"
>jdev@conference.jabber.org</TT
>—works
in a similar way to the LDAP reflector in
<A
HREF="x5334.htm#JABTDG-CH-5A-SECT-2.5.1"
>the section called <I
>Descending the browse hierarchy from an LDAP reflector</I
></A
>. There's no real distinction between
conferencing service <I
CLASS="EMPHASIS"
>usernames</I
> in the same way that
there's a distinction in the JSM service, but that part of the JID is used
to identity each room hosted by that service.</P
></BLOCKQUOTE
></DIV
><P
>We see that the “friendly” name of the JDEV room is “Development Room” and
that we need to specify a nickname in order to gain entry. There are no other
requirements (such as a secret password) that would have been
identified with an extra <TT
CLASS="LITERAL"
><secret/></TT
> tag in
the results.</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq type='result' id='c2' to='qmacro@jabber.org/hailsham'
from='jdev@conference.jabber.org'>
<query xmlns='jabber:iq:conference'>
<name>Development Room</name>
<nick/>
</query>
</iq></PRE
></P
><P
>We choose a nickname, and send this back in an IQ set request.</P
><P
>Before doing this, we must send our presence to the room to invoke the
Availability Tracker, which is described in <A
HREF="x4089.htm#JABTDG-CH-5-SB-5"
>the sidebar <I
>Availability Tracker</I
></A
>.
More information on joining and interacting with conference rooms can be
found in <A
HREF="x8004.htm"
>the section called <I
>Keyword assistant</I
> in Chapter 8</A
>.</P
><P
><PRE
CLASS="SCREEN"
>SEND: <presence to="jdev@conference.jabber.org"/>
SEND: <iq to="jdev@conference.jabber.org" type="set" id="c3">
<query xmlns="jabber:iq:conference">
<nick>qmacro</nick>
</query>
</iq></PRE
></P
><P
>The Conferencing service acknowledges our entry to the room with our chosen
nickname, having assigned
us an anonymous handle in the <TT
CLASS="LITERAL"
><id/></TT
> tag:</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq to='qmacro@jabber.org/winjab' type='result' id='c3'
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -