[Juser] IM requirements

[Peter Saint-Andre]

Hi Steve,

This is a big list. Jabber does most of this, but in part it depends on
which client and server you use. There are open-source implementations
for both clients and servers, so naturally you or your team (or someone
you convince on the developer mailing list [1]) could add the features 
you require that are not part of existing software.

I would suggest that you download the jabberd server [2], check out a
few clients [3], and see where the gaps are.

More comments inline.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

[1] http://mailman.jabber.org/listinfo/jdev/
[2] http://jabberd.jabberstudio.org/
[3] http://www.jabber.org/user/clientlist.php

On Sat, Aug 23, 2003 at 08:11:19PM -0400, Steve Auerweck wrote:
> I'd like to describe features that I'm looking for in an instant-messaging
> product, and ask if any Jabber version comes close. (Or any product at all,
> if you want to offer suggestions.) If there is none, perhaps a developer
> could find some pointers here.
> 
> Believe it or not, I'm trying to duplicate many functions found in a
> proprietary-hardware system used in my company, a large newspaper, for many
> years, beginning in the mid-'80s. The designers just got it right; I've been
> searching the net, but can't find anything fits these requirements, which I
> don't think are all that peculiar. I'm going to offer examples from the
> newspaper business, but I believe other realtime operations, like stock
> trading or law enforcement, for example, would have very similar situations.
> Here's a recap:
> 
> CLIENT:
> --Allow maintaining a >very< small window (possibly one line deep), with the
> option to keep it on top, that shows the sender and the subject or the start
> of the most recent message. This lets users keep an eye on what's going by
> and respond only to those messages that really demand it. It's very
> intrusive to have a large message window on the screen all the time, or to
> have to open a window after a beep merely to learn that someone's kid is
> selling Girl Scout cookies.

This is a client option. Not sure what you mean by "one line deep" but
some of the existing clients have a small footprint on the desktop.

> --Summary should show the name of the destination group, if it's a group
> message. Many times, users must respond differently if it's a one-on-one
> message vs. a group message. Or sometimes knowing >who< got a particular
> message is as important as the content. But that identification should be
> done by group name, rather than providing a list of names of people who
> received it, because a group may include hundreds of users.

Most Jabber clients treat groupchat differently than single chat.

> --Provide various audible/visible alert options.

Most Jabber clients do this.

> --Allow simultaneous signons, with alerts going to each instance (some
> editors move to a PC on the newsroom floor without shutting down the machine
> in their office).

Yep, Jabber does this.

> --Preferably use a "push" architecture for message delivery, rather than one
> based on polling. Alerts should occur in near realtime, and polling at such
> a rate generates too much traffic.

Ick, no polling in Jabber, it's all push.

> --Allow a user to be part of multiple groups, but don't force messages to a
> separate window for each group. A great option would be multi-window vs.
> single window.--All users should be able to check a directory for the names
> that are part of a particular group.--The option to create personal groups
> is good.

Done.

> --Allow storing of messages for later delivery if the user is offline, and
> allow user to archive messages.

Done.

> --Provide notification when recipient is offline and give option of sending
> or canceling at that point. Do not provide such notification for each member
> of a group, however -- only for a single recipient.

Possible but not commonly implemented. We use presence instead to know
when someone is online or offline.

> --But allow the option of not delivering to those who are offline. Ideally,
> that option could be invoked as part of a group definition, or by a user
> when sending to a group. Case in point: You have a group with all sports
> copy editors, which you're using to send out messages about stories being
> delayed, or being moved from page to page, etc. Only the editors who are
> working >that< night have a need for such material.

We'd handle this by having a groupchat room for all the sports copy
editors, if you're working that night you'll be in the room.

> SERVER/ADMINISTRATION:
> --Destinations are user-based, not machine-based. Integration with NT/Active
> Directory a plus.

Oh yeah, address is all user-based in Jabber. Possible to integrate with
existing NT userspace depending on which server you use. 

> --Administrator-defined groups are essential. Users won't even necessarily
> want to know the names of the members of the group they're addressing, just
> that they're getting all the police reporters, or department heads, or
> whatever.
> --I'd love for a security level that would let department managers create
> groups for everyone in the department to use.

We generally call this something like "shared groups". It's not a
standard part of Jabber setups, though there are scripts to make this
happen on the server side. But we could fairly easily define a protocol
for this -- I've been planning to do that for a few months now, just
been awfully busy with other stuff.

> --Have the ability (API) to generate messages programatically without too
> much effort. We could use that, for example, to write a daemon that monitors
> a directory, or hardware, or whatever, then sends instant messages to alert
> users/managers to important conditions.

Very easy to write such daemons and bots in Jabber. The protocol is all
open and there are libraries for just about every programming language
(see <http://www.jabber.org/developer/librarylist.php>).

> So, does anyone know about my dream product?? Or just want to comment?

Sounds like Jabber to me. :)

> Thanks in advance.

Sure thing, sorry for the slow response time.

> P.S. If anyone can discuss a general instant-messaging forum somewhere, I'd
> love to hear about it.

I don't know of one, sorry.

Peter