[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[JDEV] [Clients 1.0]
#### Intro
A Jabber client is simply an application that talks to the Jabber
server(really talking to a Jabber Transport) using a simple text/xml
protocol over a single TCP connection.
Clients can be incredibly simple or large full blown interactive
applications. There might be a simple command line app that sends
anonymous messages to a Jabber user, or maybe a background server
application that signals to a Jabber user when there are errors. There
can be normal GUI buddy-list like apps, and there might a game that uses a
Jabber server to pass information to another player to set up a direct
socket and start a network game. It can be built into a web browser to
have interactive discussions with other visitors to a web page and see the
page owners current online status and talk to them, or the client could be
a simple CGI script on the server accessed through an HTML form. A client
could even be built into a cellular phone or wireless handheld device to
see the owners current status and send them messages instantly, or the
client could be a server app that forwards messages to a pager. All of
these are possible :)
#### Security
It's been proposed that a client could implement secure communications
similar to email, using a PGP-style encryption. Either messages could be
signed to guarantee identity of the sender, or completely encrypted to
hide their contents. All of the extra encryption data or signatures could
possibly be sent along with the messages in the <ext></ext> extension
tags.
#### GUI
Some of the issues that a client implementing a GUI will need to take into
account, is how users are named. All users are identified by their ID
such as user@jab.server.com. Every user may have multiple "sessions"
where they are logged into their account more than once, each session is
identified by the nickname they choose when they start that session. So
on a roster list showing online and offline users, a client might have a
tree like:
Users--
|- fred@jabber.org (online)
| |- web server shell
| |- WaterBoy at work
|- jane@jabber.org (offline)
Above, fred is on at work and through a shell account, and jane isn't on
at all. To make things even easier for the user to view, the client could
do some name mangling and hide the user@server.com address with something
the user might type in, OR, if there is only ONE session active for that
user it could just place that session overtop the address, so when jane
comes online it might look like:
Users--
|- fred@jabber.org (online)
| |- web server shell
| |- WaterBoy at work
|- GIJane (online)
This way, when special users like ICQ users(12343@ICQ) can be displayed
consistently with Jabber users in a nice way. The client shouldn't be
differentiating between different types of accounts at all(since it can't
always tell they are different).
#### Multi-Clients
There are two ways the server will talk to a client, either as a single
user or as a multi-user proxy. All this means, is that clients can be
written that make a single TCP connection to the server but send/receive
data for multiple users. When this happens, the client/server identifies
each chunk of XML data with the session it's for.
This is most useful for:
Unix daemon that automatically registers local users when they login to the server.
Web server CGI background process, placeholder for sessions through web interface.
Simple client-proxies, possibly useful for tunneling through firewalls.
Devices, like a pager server, that logs in on behalf of multiple users and accepts special messages