?? x53.htm
字號:
<HTML
><HEAD
><TITLE
>The History Of Jabber</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="Preface"
HREF="c7.htm"><LINK
REL="NEXT"
TITLE="IM System Features"
HREF="x118.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="c7.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 1. Preface</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x118.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="JABTDG-PREFACE-SECT-2"
>The History Of Jabber</A
></H1
><P
>Jeremie Miller started the Jabber project in early 1998 and it was announced
to the public in January 1999. To understand why Jabber came about, and in
the form it took, let's look briefly at what existed in the IM world before
Jabber.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN56"
>The pre-Jabber history</A
></H2
><P
>IM existed as a concept and a handful of systems from companies such as
Mirabilis, AOL, Microsoft and Yahoo!. These systems (ICQ from Mirabilis,
AIM from AOL, MSN from Microsoft, and Yahoo!IM from Yahoo!) allowed their
users to chat to one another and avail themselves of IM-related services.
However, an AIM user couldn't chat with an ICQ user, and MSN users couldn't
interact with Yahoo!IM users. Each system was effectively closed
to the outside world.</P
><P
>Furthermore, the protocols that these systems used were also closed
—proprietary—which meant it was difficult to find clients for
these IM systems other than the ones supplied by the IM system owner.</P
><P
>Finally, the systems themselves were monolithic: multiple clients but
a single server (or server farm). Although the companies were able to invest
time and money into the problem, the fact remained that a monolithic
architecture presented a scaling problem. Perhaps more relevant than
that, companies who wanted to use IM services internally had to accept
the fact that the conversations would be carried through the systems of
a third party—namely the owners of these public IM systems. This was
no more desirable than for a company to run their internal email using
a public email service such as Hotmail.</P
><P
>Of course, these systems did have their advantages. The clients were
accomplished and easy to learn and use; and as long as your correspondents
were using the same IM system, and you didn't mind your messages being
carried by another organization (for private individuals these wouldn't
be unique circumstances; again, we are led to the email services
parallel) then you could leave the system management to someone else and
get on with chatting.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN62"
>Scratching an itch</A
></H2
><P
>Having all your contacts use the same IM system is all well and good in
theory, but in practice is rarely the case. (If, like me, you have few
friends, then this is not so much of a problem). Jeremie Miller had
correspondents in different IM systems, and consequently had to
have different IM clients running on his desktop to keep up with
them all.
Many great software projects stem from a personal "itch" that someone
wanted to scratch. This was the primary itch that Jeremie had. A single
client for all IM interaction: <I
CLASS="EMPHASIS"
>panacea</I
>.</P
><P
>Of course, one obvious solution would be to build a single client
that supported all of the IM system protocols, but this approach had
two drawbacks:</P
><P
></P
><UL
><LI
><P
>The proprietary nature of the protocols made it harder to implement the
support required and would make the client overly complicated.</P
></LI
><LI
><P
>Every time the protocol, which wasn't under his control, changed, or a
new one came along, the client would have to be modified—a task
not practical for a large user base.</P
></LI
></UL
><P
>On top of that, GUI programming isn't everyone's cup of tea, and
Jeremie preferred a solution that allowed him to concentrate on the
underlying problems at hand and let others build the GUIs.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN73"
>And then came Jabber</A
></H2
><P
>So Jeremie resolved to create a solution that had the following
characteristics:</P
><P
></P
><UL
><LI
><P
>It would have its own internal protocol, based upon XML.</P
></LI
><LI
><P
>This protocol should be:</P
><P
></P
><UL
><LI
><P
>Simple to understand and implement.</P
></LI
><LI
><P
>Easy to extend.</P
></LI
><LI
><P
>Open.</P
></LI
></UL
></LI
><LI
><P
>The complexity of bridging the disparate proprietary IM protocols
would remain at the server, each bridge being a plug-in module.</P
></LI
><LI
><P
>All the clients would only have to implement the single, simple
internal protocol; everything else would be implemented at the server.</P
></LI
></UL
><P
>He called this solution "Jabber."</P
><P
>At the same time, perhaps because he didn't consider himself a large
organization with the resources to run a centralized server service,
this architecture feature was fundamental:</P
><P
></P
><UL
><LI
><P
>Anyone could implement a server of their own.</P
></LI
></UL
><P
>In the same way that email is not a centralized service—
each mail user has an address that corresponds to where their mailbox is
held—the system that Jeremie envisioned was a decentralized one. This
meant that individuals, companies and public organizations could run
their own servers—especially relevant for internal-only, IM-style corporate
communication. Just as email servers exchange mail using Simple
Mail Transfer Protocol (SMTP), so the Jabber servers would connect and exchange
IM traffic when necessary.</P
><DIV
CLASS="FIGURE"
><A
NAME="AEN98"
></A
><P
><B
>Figure 1-1. The Distributed Architecture of Jabber</B
></P
><PRE
CLASS="SCREEN"
> +--------+
| Jabber |
| client | +--------+
+--------+ | Jabber |
| | server | +....................+
+------ | | : :
| | : Internet :
+--------+ : :
| : :
+--------: :-------+
: : |
: : +--------+
: : | Jabber |
+....................+ | server |
| | -----+
| | |
+--------+ +--------+
| Jabber |
| client |
+--------+</PRE
></DIV
><P
>Being <I
CLASS="EMPHASIS"
>open</I
> meant that Jabber could benefit from the
help of anyone who wished to lend a hand, and administrators were empowered
to be able to find and fix problems themselves if they so wished.</P
><P
>Being <I
CLASS="EMPHASIS"
>XML-based</I
>, as opposed to some other binary format
for example, meant that the protocol streams were easy for humans to read,
extensible, and readily integrated (there is a great range of XML parsing
and construction tools already available).</P
><P
>Being <I
CLASS="EMPHASIS"
>distributed</I
> meant that the Jabber system would
belong to the people, and that some of the scalability problems
would be avoided.
<A
NAME="SCALABILITY"
HREF="#FTN.SCALABILITY"
>[1]</A
></P
><P
>All of these features made for a good IM system design. But why stop at IM?
Consider the client as an implementation of a simple protocol to exchange
messages and presence information in XML structures, and use plug-in services
at the server, and what do you have?</P
><P
><I
CLASS="EMPHASIS"
>A language and platform agnostic XML routing framework.</I
></P
><P
>Good grief, what a mouthful! This is why my response to "What is Jabber?"
is usually just:</P
><P
><I
CLASS="EMPHASIS"
>A really</I
> great <I
CLASS="EMPHASIS"
>technology!</I
></P
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.SCALABILITY"
HREF="x53.htm#SCALABILITY"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>There remain some scalability issues of course. Client-server communication
that is TCP socket based suffers from limitations of this technology. There
are however initiatives to overcome these limitations with multiplexing
techniques such as <TT
CLASS="LITERAL"
>jpolld</TT
> and <TT
CLASS="LITERAL"
>dpsm</TT
>.</P
></TD
></TR
></TABLE
><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="c7.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="x118.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Preface</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c7.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>IM System Features</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -