[JDEV] Protocol bits and discussion

Jeremie jeremie at jabber.org
Wed Jun 2 11:47:09 CDT 1999

There are some parts of the protocol that haven't been fully defined yet
as to what their range of values might be.  I'll try to explain my
intentions for them and we can discuss any variations/changes that need to
happen.  I'll also post these to the site when ready.

First, the login packet:
	<nick>test user</nick>

The user/pass fields are obvious, but the nick field is the unique
identifier for this "session" and is what clients should use when
displaying the session.  It's similiar to email where 
"Jeremie <jer at jeremie.com>" is user=jer at jeremie.com and nick=Jeremie.

Now, the message packet:
	<to nick='you'>someone</to>
	<subject>Did you see that?</subject>
	<say>asdgf asdfkjasgoijqwert asdgaldgjkas</say>

## <to nick='you'>someone</to>
Contains the recipient id, and the nick attribute suggests a specific
session of that recipient to send this message to.

## <thread>sdfa</thread>
This is a special field for threading conversations in clients or for
group chats.  This is optional for a client to support, but is suggested
if possible.  Anytime a user specifically creates a new message or new
"thread" (depends on client's gui), a new semi-random string should be
placed in the thread, and when the recipient receives this message+thread,
it should simply echo the thread value back in any direct responses.  When
the orginal sender gets a thread back, it should display that message in
the same window, similiar to AIM or many IRC/chat interfaces.  This is a
fairly powerful field, and will be better defined as more clients mature
and start to utilize it.

## <priority>1</priority>
Again, an optional field and probably almost always not used(zero by
default).  It is suggested that modules ignore messages with a priority
below zero(won't be stored offline) and clients depreciate any major
notification(audio alerts, popups, etc) for sub-zero. A range needs to be
specified for other special cases though:
	1-1000	notify even when status is busy/NA
	1000+	top priority, client should popup/display first in list
The range is so that specific actions can be defined later, and general
actions can be used if a specific is unknown.

## <subject>blah</subject>
Optional, just to give a "preview" or topic of a message before/during
reading or when browsing history/logs.

## <say>sadfasdf</say>
Required, contains the text to display.

The status packets:
<status type='online'>
	<say>This is my status</say>

First, the type='' attribute can ONLY be 'online' and 'offline' at this
point.  This is not the place for all of the sub-types like
away/not-available/etc.  And <say></say> is where a user can type in their
own status message or reason for being away, etc.  This can be a tooltip
or popup or such. 

## <priority>10</priority>
This is going to be a tricky and special field, and is required to be sent
for at least the initial status packet(else it will default to zero). The
primary use for this field is by the server to determine which "session"
of a users is the primary one.  So, incoming messages sent to the user
will be delivered to the primary session. Basically, the lowest positive
priority is the primary session.  This is so that the priority field can
roughly estimate minutes idle.  The user should be able to control this
and any automation, but a client might automatically send a new status
packet with a higher priority every five minutes or so.  So: 
<status><say>At Work</say><priority>35</priority></status> would mean this
user has been away from their desk for 35 minutes.  All priorities below
zero are for special devices that should not be considered normal
sessions, such as a pager, and should never be considered a "primary" 

## <icon>normal</icon>
THIS is where normal types go.  Here are a few possibilites:
and also maybe fun ones like:
or activity ones:
This list needs to be standardized so clients being developed can assign
actual icons to these values.

I'm getting the feeling that I need to dedicate a whole email to
explaining statuses, sessions, and how they all work/interact :)


More information about the JDev mailing list