📄 x118.htm
字号:
<HTML
><HEAD
><TITLE
>IM System Features</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="Preface"
HREF="c7.htm"><LINK
REL="PREVIOUS"
TITLE="The History Of Jabber"
HREF="x53.htm"><LINK
REL="NEXT"
TITLE="What's Inside"
HREF="x151.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="x53.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 1. Preface</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x151.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="JABTDG-PREFACE-SECT-3"
>IM System Features</A
></H1
><P
>This book assumes you have a basic knowledge of features commonly found in IM
systems. In case you haven't, here's a brief rundown of features relevant to
what we'll be covering:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Presence</DT
><DD
><P
>In many cases,
there's not much point in sending a quick message to someone if they're not
there. <I
CLASS="EMPHASIS"
>Presence</I
> is a term used in IM to describe the
technique of exchanging information, in a controlled manner, about availability
(or unavailability).</P
><P
>The idea is that when you connect to your IM server, your client sends an
"I'm here" message which is relayed to your correspondents. It does the
opposite when you disconnect. During the time you're connected you can
vary the information about your availability to reflect your immediate
situation ("just popped out for coffee," "working on my resume—don't
disturb me!").</P
></DD
><DT
>Buddy List/Roster</DT
><DD
><P
>Both terms (the former comes from the original IM systems, the latter from
Jabber) refer to a list of correspondents with whom you regularly communicate
and receive presence information from. Depending on the IM system, the list
may be stored on the client or on the server. Storing the list on the
client has the (tenuous) advantage of being accessible when you're not
connected to the server. Storing the list on the server means that you have a
consistent roster content regardless of the client or workstation you happen
to use—the list travels with you.</P
><P
>Jabber stores this list—the roster—at the server.</P
></DD
><DT
>Push and Pull</DT
><DD
><P
>When you connect to an IM system, there may be information the client needs
to retrieve—<I
CLASS="EMPHASIS"
>pull</I
>—from the server (the roster, for
instance). This is under direct control of your client as it decides when to
make the retrieval. During the course of the connection, you'll receive
messages from your correspondents. You don't request these messages by
making a <I
CLASS="EMPHASIS"
>retrieve call</I
> to the server, as you would with the Post
Office Protocol (POP) or Internet Message Access Protocol (IMAP) protocols to
retrieve email messages from the mail server; they're
<I
CLASS="EMPHASIS"
>push</I
>ed to you as they occur.</P
><P
>In other words, you could say that the client must implement an event-based
system, to listen out for and subsequently handle the incoming information,
by displaying a popup window containing the chat message, for example.</P
><P
>The push/pull system lends itself well to traffic other than IM traffic.</P
></DD
><DT
>Client-Server</DT
><DD
><P
>It almost goes without saying that, like other IM systems, Jabber has a
client-server architecture. Clients, and client libraries that implement the
Jabber protocol, such as Net::Jabber, JabberPy, and Jabberbeans, are available for
many languages (here, for Perl, Python, and Java, respectively).</P
><P
>With Jabber, it is especially relevant to stress that the "weight balance"
in complexity terms, between the client and the server, comes down heavily
on the server side. Not only does this mean that the complexity remains
where it should be—on the server—but also makes the task of writing
clients easier and the resulting software lighter.</P
></DD
><DT
>Multiple vs Single Server</DT
><DD
><P
>We've already mentioned that the Jabber architecture does not dictate a
single, centralized server. Not only does this mean that organizations can
implement their own private system, but also that developers are free to
install their own server and develop new plug-in services in addition to the
IM bridges already available.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x53.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x151.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>The History Of Jabber</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c7.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>What's Inside</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -