📄 x9016.htm
字号:
><P
>Let's take a leaf out of other components' books. There's a common
theme that binds together components such as the JUD (Jabber User Directory),
and the Transports to other IM systems such as Yahoo! and ICQ. This theme
is <I
CLASS="EMPHASIS"
>registration</I
>. We've seen this before in the form
of <I
CLASS="EMPHASIS"
>user registration</I
>, described in
<A
HREF="x6351.htm"
>the section called <I
>User Registration</I
> in Chapter 6</A
>. This is the process of creating a
new account with the JSM.
Registration with a <I
CLASS="EMPHASIS"
>service</I
>
such as the JUD, or an IM transport, however, follows a similar process.
And both types of registration have one thing in common:</P
><P
><TT
CLASS="LITERAL"
>jabber:iq:register</TT
></P
><P
>The <TT
CLASS="LITERAL"
>jabber:iq:register</TT
> namespace is what's used in
all cases to qualify the exchange of information during a registration
process.
<A
NAME="AEN9276"
HREF="#FTN.AEN9276"
>[6]</A
>
<A
HREF="x5334.htm#JABTDG-CH-5A-SECT-2.11"
>the section called <I
><TT
CLASS="LITERAL"
>jabber:iq:register</TT
></I
> in Chapter 5a</A
> describes the
<TT
CLASS="LITERAL"
>jabber:iq:register</TT
> namespace. It shows us how
a typical conversation between requester and responder takes place:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>The client sends an IQ-get: "<I
CLASS="EMPHASIS"
>How do I register?</I
>"</P
></LI
><LI
><P
>The component sends an IQ-result: "<I
CLASS="EMPHASIS"
>Here's how.
Follow these instructions to fill in these fields.</I
>"</P
></LI
><LI
><P
>The client then sends an IQ-set with values in the fields:
"<I
CLASS="EMPHASIS"
>Ok, here's my registration request.</I
>"</P
></LI
><LI
><P
>To which the component responds, with another IQ-result:
"<I
CLASS="EMPHASIS"
>Looks fine. Your registration details have been stored.</I
>"</P
></LI
></OL
><P
>It's clear that this sort of model will lend itself well to the
process of allowing users to make requests to receive pointers to
new items from RSS sources chosen from a list.
<A
HREF="x9016.htm#JABTDG-CH-8-EX-12"
>Example 8-12</A
> shows this conversational model
in Jabber XML. There are many fields that can be used in a registration
request; the description in <A
HREF="x5334.htm#JABTDG-CH-5A-SECT-2.11"
>the section called <I
><TT
CLASS="LITERAL"
>jabber:iq:register</TT
></I
> in Chapter 5a</A
>
includes a few of these—
<TT
CLASS="LITERAL"
><name/></TT
>,
<TT
CLASS="LITERAL"
><first/></TT
>,
<TT
CLASS="LITERAL"
><last/></TT
>, and
<TT
CLASS="LITERAL"
><email/></TT
>—but there are more. We'll
take the <TT
CLASS="LITERAL"
><text/></TT
> field to accept the
name of an RSS source when a user wishes to register his interest to receive
pointers to new items from that source. The conversational model is
shown from the component's perspective. </P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-8-EX-12"
></A
><P
><B
>Example 8-12. A registration conversation for RSS sources</B
></P
><P
>"<I
CLASS="EMPHASIS"
>How do I register?</I
>"</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq type='get' id='JCOM_3' to='rss.qmacro.dyndns.org'
from='dj@qmacro.dyndns.org/basement'>
<query xmlns='jabber:iq:register'/>
</iq> </PRE
></P
><P
>"<I
CLASS="EMPHASIS"
>Here's how:</I
>"</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq id='JCOM_3' type='result' to='dj@qmacro.dyndns.org/basement'
from='rss.qmacro.dyndns.org'>
<query xmlns='jabber:iq:register'>
<instructions>
Choose an RSS source from: Slashdot, JonUdell[, ...]
</instructions>
<text/>
</query>
</iq> </PRE
></P
><P
>"<I
CLASS="EMPHASIS"
>Ok, here's my registration request:</I
>"</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq type='set' id='JCOM_5' to='rss.qmacro.dyndns.org'
from='dj@qmacro.dyndns.org/basement'>
<query xmlns='jabber:iq:register'>
<text>Slashdot</text>
</query>
</iq> </PRE
></P
><P
>"<I
CLASS="EMPHASIS"
>Looks fine. Thanks.</I
>"</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq id='JCOM_5' type='result' to='dj@qmacro.dyndns.org/basement'
from='rss.qmacro.dyndns.org'>
<query xmlns='jabber:iq:register'>
<text>Slashdot</text>
</query>
</iq> </PRE
></P
><P
>(Time passes...)</P
><P
>"<I
CLASS="EMPHASIS"
>Whoa. I want out!</I
>"</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq id='JCOM_11' to='rss.qmacro.dyndns.org' type='set'
from='dj@qmacro.dyndns.org/basement'>
<query xmlns='jabber:iq:register'>
<remove/>
</query>
</iq> </PRE
></P
><P
>"<I
CLASS="EMPHASIS"
>Ok, you're out.</I
>"</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq id='JCOM_11' to='dj@qmacro.dyndns.org/basement' type='result'
from='rss.qmacro.dyndns.org'>
<query xmlns='jabber:iq:register'>
<remove/>
</query>
</iq> </PRE
></P
></DIV
><P
>We'll use a lightweight persistent storage system for our user/source
registrations—DBM—to keep the script fairly simple. </P
><P
>One more thing, before we leave this registration section. How will the
users know that they can register? What's even more critical—how
will they know that the RSS punter actually exists?
<A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.1.3.8"
>the section called <I
>Browsable Service Information</I
> in Chapter 4</A
> explains the way that
services can be described, <I
CLASS="EMPHASIS"
>announced</I
> even, by the
JSM. Most clients, having connected to the server and established a
session with the JSM, make a request for a list of <I
CLASS="EMPHASIS"
>agents</I
>
(old terminology) or <I
CLASS="EMPHASIS"
>services</I
> (new terminology) that
are available on that Jabber server, like this:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq id="wjAgents" to="qmacro.dyndns.org" type="get">
<query xmlns="jabber:iq:agents"/>
</iq> </PRE
></P
><P
>The response to the request, which looks like this:</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq id='wjAgents' to='dj@qmacro.dyndns.org/basement'
type='result' from='qmacro.dyndns.org'>
<query xmlns='jabber:iq:agents'>
<agent jid='conf.qmacro.dyndns.org'>
<name>Public Chatrooms</name>
<service>public</service>
<groupchat/>
</agent>
<agent jid='users.jabber.org'>
<name>Jabber User Directory</name>
<service>jud</service>
<search/>
<register/>
</agent>
</query>
</iq> </PRE
></P
><P
>reflects the contents of the <TT
CLASS="LITERAL"
><browse/></TT
>
section in the JSM configuration as shown in
<A
HREF="x9016.htm#JABTDG-CH-8-EX-13"
>Example 8-13</A
>.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-8-EX-13"
></A
><P
><B
>Example 8-13. The JSM configuration's <TT
CLASS="LITERAL"
><browse/> section</TT
></B
></P
><P
><PRE
CLASS="SCREEN"
><browse>
<conference type="public" jid="conf.qmacro.dyndns.org"
name="Public Chatrooms"/>
<service type="jud" jid="users.jabber.org" name="Jabber User Directory">
<ns>jabber:iq:search</ns>
<ns>jabber:iq:register</ns>
</service>
</browse> </PRE
></P
></DIV
><P
>If we <I
CLASS="EMPHASIS"
>add</I
> a stanza for our RSS punter to the
<TT
CLASS="LITERAL"
><browse/></TT
> section of the JSM configuration,
that described our component, like this:</P
><P
><PRE
CLASS="SCREEN"
><service type="rss" jid="rss.qmacro.dyndns.org" name="RSS punter">
<ns>jabber:iq:register</ns>
</service> </PRE
></P
><P
>then we'll end up with an extra section in the
<TT
CLASS="LITERAL"
>jabber:iq:agents</TT
> response from the server:</P
><P
><PRE
CLASS="SCREEN"
><agent jid='rss.qmacro.dyndns.org'>
<name>RSS punter</name>
<service>rss</service>
<register/>
</agent> </PRE
></P
><P
>The client-side effect of the agents response is exactly what we're
looking for. <A
HREF="x9016.htm#JABTDG-CH-8-FIG-7"
>Figure 8-6</A
> shows WinJab's
<I
CLASS="EMPHASIS"
>Agents</I
> menu displaying a summary of what it
received in response to its <TT
CLASS="LITERAL"
>jabber:iq:agents</TT
>
query. We can see that the stanza for our RSS punter was present
in the <TT
CLASS="LITERAL"
><browse/></TT
> section and the component
is faithfully
displayed in the agent list, along with "Public Chatrooms" and
"Jabber User Directory". In the main window of the screenshot we can
see the "Supported Namespaces" list; it contains the namespace that
we specified in our stanza. By specifying </P
><P
><PRE
CLASS="SCREEN"
><ns>jabber:iq:register</ns></PRE
></P
><P
>we're effectively telling the client that the component will support
a registration conversation. </P
><DIV
CLASS="FIGURE"
><A
NAME="JABTDG-CH-8-FIG-7"
></A
><P
><B
>Figure 8-6. WinJab's "Agents" menu</B
></P
><P
><IMG
SRC="CH-8-FIG-7.jpg"></P
></DIV
><P
>But that's not all! We've advertised our RSS punter in the
<TT
CLASS="LITERAL"
><browse/></TT
> section of the configuration
for the JSM on the Jabber server running on
<TT
CLASS="LITERAL"
>qmacro.dyndns.org</TT
>. That's why we got the information
about the RSS punter agent when we connected as user <I
CLASS="EMPHASIS"
>dj</I
>
to <TT
CLASS="LITERAL"
>qmacro.dyndns.org</TT
>—see the window's title bar in
<A
HREF="x9016.htm#JABTDG-CH-8-FIG-7"
>Figure 8-6</A
>. You may have noticed something
odd about the definition of the other two agents, or services, in the
<TT
CLASS="LITERAL"
><browse/></TT
> section earlier, or in the
corresponding <TT
CLASS="LITERAL"
>jabber:iq:agents</TT
> IQ response. Let's
take a look at this response again, this time with the extra detail
about our component:</P
><P
><PRE
CLASS="SCREEN"
>RECV: <iq id='wjAgents' to='dj@qmacro.dyndns.org/basement'
type='result' from='qmacro.dyndns.org'>
<query xmlns='jabber:iq:agents'>
<agent jid='rss.qmacro.dyndns.org'>
<name>RSS punter</name>
<service>rss</service>
<register/>
</agent>
<agent jid='conf.qmacro.dyndns.org'>
<name>Public Chatrooms</name>
<service>public</service>
<groupchat/>
</agent>
<agent jid='users.jabber.org'>
<name>Jabber User Directory</name>
<service>jud</service>
<search/>
<register/>
</agent>
</query>
</iq> </PRE
></P
><P
>Imposter alert! While the <TT
CLASS="LITERAL"
>jid</TT
> attribute values
for the RSS punter and Public Chatrooms agents show that they are
components that are connected to the Jabber server we've just
authenticated with (i.e. they both have JIDs in the
<TT
CLASS="LITERAL"
>qmacro.dyndns.org</TT
> "space", and so are connected
to the Jabber server running at <TT
CLASS="LITERAL"
>qmacro.dyndns.org</TT
>), the
<TT
CLASS="LITERAL"
>jid</TT
> attribute for the Jabber User Directory points
to a name in the <TT
CLASS="LITERAL"
>jabber.org</TT
> "space"!
This is actually perfectly ok,
and indeed is a side-effect of the power and foresight of Jabber's
architectural design. If we connect a component, whether it's one
we've built ourselves or one we've downloaded from the
<A
HREF="http://download.jabber.org"
TARGET="_top"
>http://download.jabber.org</A
>
site, we can give it an <I
CLASS="EMPHASIS"
>internal</I
> or an
<I
CLASS="EMPHASIS"
>external</I
> identity when we describe it in the
<TT
CLASS="FILENAME"
>jabber.xml</TT
> configuration.</P
><P
><A
HREF="x9016.htm#JABTDG-CH-8-EX-8"
>Example 8-8</A
> and <A
HREF="x9016.htm#JABTDG-CH-8-EX-9"
>Example 8-9</A
>
show two examples of an instance definition for our RSS
punter component. Both specify potentially <I
CLASS="EMPHASIS"
>external</I
>
identities. What this means is that if the hostname
<TT
CLASS="LITERAL"
>rss.qmacro.dyndns.org</TT
> is a valid and resolvable
hostname, the component can be reached from anywhere, not just from
within the Jabber server to which it is connected. If the hostname
wasn't resolvable by the outside world, by having a simple name such as
<TT
CLASS="LITERAL"
>rss</TT
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -