📄 x4089.htm
字号:
<HTML
><HEAD
><TITLE
>The Jabber Building Blocks</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
"><LINK
REL="HOME"
TITLE="Programming Jabber"
HREF="book1.htm"><LINK
REL="UP"
TITLE="Jabber Technology Basics"
HREF="c3612.htm"><LINK
REL="PREVIOUS"
TITLE="XML Streams"
HREF="x3837.htm"><LINK
REL="NEXT"
TITLE="Jabber Namespaces"
HREF="c5281.htm"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Programming Jabber</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x3837.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 5. Jabber Technology Basics</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="c5281.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="JABTDG-CH-5-SECT-5.4"
>The Jabber Building Blocks</A
></H1
><P
>At this stage we've got a good impression of the structure of Jabber;
what different elements make up a Jabber system, how
entities in Jabber are addressed, and how communication between these
entities is carried.</P
><P
>Now it's time to look at <I
CLASS="EMPHASIS"
>what</I
> gets carried—the
fragments that we touched upon in the previous section. These fragments
are the heart and soul of Jabber—the <I
CLASS="EMPHASIS"
>lifeblood</I
> that
courses through Jabber's veins carrying information back and forth—these
fragments in many ways define what Jabber is, what it stands for.</P
><P
>Surprisingly, when we look closely at these fragments, with Jabber's
capabilities as a messaging platform in mind, we see that there are only
three basic elements involved—<TT
CLASS="LITERAL"
><message/></TT
>,
<TT
CLASS="LITERAL"
><presence/></TT
>, and
<TT
CLASS="LITERAL"
><iq/></TT
>. Three different types of XML fragment,
each with a different purpose. But with these three fragment types, all that
Jabber promises, and more, can be achieved.</P
><P
>Now let's look at each of these Jabber elements in greater detail. But before
we do, let's dive into the XML stream and pull out a handful of XML
fragments to get us in the mood.
<A
HREF="x4089.htm#JABTDG-CH-5-EX-HANDFUL"
>Example 5-2</A
>
shows a chunk of conversation
between a Jabber client and a Jabber server which occurred immediately after
the connection and authentication stages.</P
><P
>Although any conversation between two Jabber entities is contained within
two XML documents exchanged in streams, the traditional way to represent
both documents at the same time is to use prefixes to show whether a
fragment is being sent (<TT
CLASS="LITERAL"
>SEND:</TT
>) or received
(<TT
CLASS="LITERAL"
>RECV:</TT
>), by one of the two entities. When appropriate,
the perspective is taken from the viewpoint of the entity that's
<I
CLASS="EMPHASIS"
>not</I
> the Jabber server; in the case of
<A
HREF="x4089.htm#JABTDG-CH-5-EX-HANDFUL"
>Example 5-2</A
>, the viewpoint is of the Jabber client.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-5-EX-HANDFUL"
></A
><P
><B
>Example 5-2. A Chunk of Conversation between a Jabber client and a Jabber server</B
></P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq id='roster_0' type='get'><A
NAME="IQ"
><IMG
SRC="../images/callouts/1.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(1)"></A
>
<query xmlns='jabber:iq:roster'/>
</iq>
RECV: <iq id='roster_0' type='result' from='dj@yak/Work'>
<query xmlns='jabber:iq:roster'>
<item jid='sabine@yak' name='sabine' subscription='both'>
<group>Family</group>
</item>
</query>
</iq>
SEND: <presence><status>Online</status></presence><A
NAME="PRESENCE"
><IMG
SRC="../images/callouts/2.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(2)"></A
>
... time passes ...
RECV: <message id='1' to='dj@yak' from='sabine@yak/winjab' type='chat'><A
NAME="MESSAGE"
><IMG
SRC="../images/callouts/3.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(3)"></A
>
<thread>3FE7392DDCA919CB49C73A2FFCE9901D</thread>
<body>Hello</body>
</message></PRE
></P
></DIV
><P
><A
HREF="x4089.htm#JABTDG-CH-5-EX-HANDFUL"
>Example 5-2</A
>
shows three different elements in action, described as follows:</P
><DIV
CLASS="CALLOUTLIST"
><DL
COMPACT="COMPACT"
><DT
><A
HREF="x4089.htm#IQ"
><IMG
SRC="../images/callouts/1.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(1)"></A
></DT
><DD
>The user's (<TT
CLASS="LITERAL"
>dj@yak</TT
>'s) contact list is
requested and sent back by the server
(the <TT
CLASS="LITERAL"
><iq/></TT
> elements)</DD
><DT
><A
HREF="x4089.htm#PRESENCE"
><IMG
SRC="../images/callouts/2.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(2)"></A
></DT
><DD
>The client broadcasts the user's availability
(the <TT
CLASS="LITERAL"
><presence/></TT
> element)</DD
><DT
><A
HREF="x4089.htm#MESSAGE"
><IMG
SRC="../images/callouts/3.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(3)"></A
></DT
><DD
>The user receives a message from <TT
CLASS="LITERAL"
>sabine@yak</TT
>
(the <TT
CLASS="LITERAL"
><message/></TT
> element)</DD
></DL
></DIV
><P
>So, let's have a look at each of these elements, starting with
arguably the most commonly
occurring—<TT
CLASS="LITERAL"
><message/></TT
>.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5-SECT-5.4.1"
>The Message Element</A
></H2
><P
>It's obvious that in a messaging architecture such as Jabber, sending messages
is fundamental. The
<TT
CLASS="LITERAL"
><message/></TT
>
element provides us with this facility. Any data, other than
availability information or structured requests and responses (which are
handled by the other two element types) sent from one Jabber entity to another,
is sent in a <TT
CLASS="LITERAL"
><message/></TT
> element.</P
><P
>All things considered, the keyword in that last sentence is
<I
CLASS="EMPHASIS"
>in</I
>. It's a good idea to regard Jabber elements as
<I
CLASS="EMPHASIS"
>containers</I
>; the simile fits well as the elements
themselves remain relatively static (save for the attributes) but the
<I
CLASS="EMPHASIS"
>content</I
> can change to reflect the circumstances.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-5-SECT-5.4.1.1"
>Message Attributes</A
></H3
><P
>The <TT
CLASS="LITERAL"
><message/></TT
> element is a
container, or envelope, which appropriately requires some form or
addressing. The attributes of the
<TT
CLASS="LITERAL"
><message/></TT
> element serve
this purpose.</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>type</DT
><DD
><P
><I
CLASS="EMPHASIS"
>Optional</I
></P
><P
>Example:
<TT
CLASS="LITERAL"
><message <TT
CLASS="USERINPUT"
><B
>type='chat'</B
></TT
>></TT
></P
><P
>The Jabber protocol defines five different message <I
CLASS="EMPHASIS"
>types</I
>.
The message type gives an indication to the recipient as to what sort of
content is expected; the client software is then able, if it wishes, to handle
the incoming message appropriately.</P
><P
><TT
CLASS="USERINPUT"
><B
><TT
CLASS="LITERAL"
>type='normal'</TT
></B
></TT
></P
><P
>The <TT
CLASS="LITERAL"
>normal</TT
> message type is used for simple messages that are often
one-time in nature, similar to an email message. If I send you a message
and I'm not particularly expecting a response, or a discussion to ensue,
then the appropriate message type is <TT
CLASS="LITERAL"
>normal</TT
>.</P
><P
>Some clients handle <TT
CLASS="LITERAL"
>normal</TT
> message types by placing them in a sort of
message inbox, to be viewed by the user when he so chooses. This is in
contrast to a <TT
CLASS="LITERAL"
>chat</TT
> type message.</P
><P
>Note that the <TT
CLASS="LITERAL"
>normal</TT
> message type is the default. So if a message is
received without an explicit <TT
CLASS="LITERAL"
>type</TT
> attribute,
it is interpreted as being <TT
CLASS="LITERAL"
>normal</TT
>.</P
><P
><TT
CLASS="USERINPUT"
><B
><TT
CLASS="LITERAL"
>type='chat'</TT
></B
></TT
></P
><P
>The <TT
CLASS="LITERAL"
>chat</TT
> message type differs from the <TT
CLASS="LITERAL"
>normal</TT
> message type in that it
carries a message that is usually part of a live conversation, which is
best handled in real-time with immediate responses—a <TT
CLASS="LITERAL"
>chat</TT
> session.</P
><P
>The handling of
<TT
CLASS="LITERAL"
>chat</TT
> messages in many clients is done with a single window that displays
all the <TT
CLASS="LITERAL"
>chat</TT
> messages both sent and received between the two parties
involved. All the <TT
CLASS="LITERAL"
>chat</TT
> messages that belong to the same thread of
conversation, that is. There's a subelement of the
<TT
CLASS="LITERAL"
><message/></TT
> element that allows
the identification of conversational threads so that the right messages can
be grouped together; see the reference to
<TT
CLASS="LITERAL"
><thread/></TT
> later in this section.</P
><P
><TT
CLASS="USERINPUT"
><B
><TT
CLASS="LITERAL"
>type='groupchat'</TT
></B
></TT
></P
><P
>The <TT
CLASS="LITERAL"
>groupchat</TT
> message type is to alert the receiving client that the message
being carried is one from a conference (<TT
CLASS="LITERAL"
>groupchat</TT
>) room. The user can
participate in many conference rooms, and receive messages sent by other
participants in those rooms. The <TT
CLASS="LITERAL"
>groupchat</TT
> type signifies to the receiving
client that the addressee specified in the
<TT
CLASS="LITERAL"
>to</TT
> attribute (see later in
this section) is <I
CLASS="EMPHASIS"
>not</I
> the user's JID but the JID of
the conference room whence the <TT
CLASS="LITERAL"
>groupchat</TT
> message originates.</P
><P
><TT
CLASS="USERINPUT"
><B
><TT
CLASS="LITERAL"
>type='headline'</TT
></B
></TT
></P
><P
>This is a special message type designed to carry news style information,
often accompanied by a URL and description in an attachment qualified by
the <TT
CLASS="LITERAL"
>jabber:x:oob</TT
> namespace. Messages with their <TT
CLASS="LITERAL"
>type</TT
> set to <TT
CLASS="LITERAL"
>headline</TT
> can be
handled by clients in such a way that their content is placed in a growing
list of entries that can be used as reference by the user.</P
><P
><TT
CLASS="USERINPUT"
><B
><TT
CLASS="LITERAL"
>type='error'</TT
></B
></TT
></P
><P
>The <TT
CLASS="LITERAL"
>error</TT
> message type signifies that the message is conveying error
information to the client. Errors can originate in many places and under
many circumstances. Refer to the description of the
<TT
CLASS="LITERAL"
><error/></TT
> subelement later
in this section for more details.</P
></DD
><DT
>from</DT
><DD
><P
><I
CLASS="EMPHASIS"
>Set by server</I
></P
><P
>Example:
<TT
CLASS="LITERAL"
><message <TT
CLASS="USERINPUT"
><B
>from='dj@yak/Desktop'</B
></TT
>></TT
></P
><P
>The <TT
CLASS="LITERAL"
>from</TT
> attribute of the
<TT
CLASS="LITERAL"
><message/></TT
>
element shows the message originator's JID. In many cases this is the JID
of a user, but with the message type <TT
CLASS="LITERAL"
>groupchat</TT
> for example, it can be
the JID of the conference room where the message was originally sent.</P
><P
>Note that the <TT
CLASS="LITERAL"
>from</TT
> attribute
should not be set by the client. It is the Jabber server, to which the
client where the message was originated is connected, that sets the
attribute value. This is to prevent spoofing of JIDs. If a
<TT
CLASS="LITERAL"
>from</TT
> attribute <I
CLASS="EMPHASIS"
>is</I
> set, it will
be overriden by the server.</P
></DD
><DT
>to</DT
><DD
><P
><I
CLASS="EMPHASIS"
>Optional</I
></P
><P
>Example:
<TT
CLASS="LITERAL"
><message <TT
CLASS="USERINPUT"
><B
>to='qmacro@jabber.org'</B
></TT
>></TT
></P
><P
>The <TT
CLASS="LITERAL"
>to</TT
> attribute is used to specify the intended recipient of the
message, and is a JID. The recipient may be another Jabber user, in
which case the JID will usually be in the form
<TT
CLASS="LITERAL"
>username@hostname</TT
> (with
an optional <TT
CLASS="LITERAL"
>/resource</TT
> if
a message should be sent to a specific client connection), or it could
be a Jabber server identity, in which case the JID will be in the
form <TT
CLASS="LITERAL"
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -