Technology Choices: MOO vs Jabber vs Messenger

[Terry Disz]

This is an excellent topic.

While I agree that the three technologies mentioned are obvious choices, I
don't think they are the only obvious choices. For instance, we have
available to us the intergroup chat tool from Deb Agrawal's group, and there
are plenty of open source chat systems we could grab, such as the zope based
thingy -  http://www.zope.org/Members/jwashin/ZRTChat

Anyway, I think it is hard to have this discussion about technology
candidates without having any specific requirements and constraints as
objective measurement criteria. I don't know what we want out of a text
"chat" capability, nor what we would be willing to put up with in order to
get one.

Before we can discuss which system satisfies the support and deployment
issues in the chart Ivan provided, I would like to see a discussion of what
functionality we want from the system. I know we all *think* we know what is
required, but even if the functionality requirements are simple, they need
to be written down. Here's a start.

At a minimum, the text chat system should:

1. Allow multiple people to operate in a given scope. That means it is not a
one-to-one messenger.
2. Relay text typed from one user to all others in near real time.

Those two items are actually all I can think of that I don't believe are
controversial and almost any simple method could be used to deliver this
functionality.

Here are other functional ideas that bear discussion:

Inner Scope - do we want to allow text to be sent to some subset of people
in a "room"
Outer Scope - do we allow messaging outside of the room scope? (page, @who)
Privacy - do we want to be able to whisper to individuals or sub groups?
History - do we want our current mud-like scrollback
	(implemented today with screen&emacs, or client buffering)
Recording - should things be recorded? From what perspective? Who should be
able to see it?
persistent Objects - do we need a moo like system that allows objects to be
placed in the rooms?
Message types - do we allow messages that are more than text? For instance,
can I drop an image on the chat room and have the right thing happen?
Smart text - do we require that the system provide a mechanism for clickable
items in the client?
Ordering, Consistency - Do we care if  messages are delivered to everyone in
the same order?



Here are some operational considerations

msg protocol - are there standard messaging protocols? do they do what we
need? Do we care?
Server - do we care if we have a server, or server-less system?
Client - do we require an open messaging protocol so that different clients
can be developed, or do we offer one and only one client
Weight - how much do we care how heavy the client and/or server is? That is,
how much code and supporting libraries need to be installed to use it.
Platform independence - do we care? What platforms?
Security - do we require authentication to use it? Is the transport secure?

If we can agree on a set of functional and operational requirements, we can
then put together a comparision chart to make sense of the candidates.

Thoughts?

Terry











> -----Original Message-----
> From: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov]On
> Behalf Of Ivan R. Judson
> Sent: Friday, September 13, 2002 8:33 AM
> To: 'Ag-Dev at Mcs. Anl. Gov'
> Subject: Technology Choices: MOO vs Jabber vs Messenger
>
>
>
> Here's another choice that might make design and implementation of 2.0
> faster if we all agree: MOO or Jabber or ???.
>
> The obvious three choices are MOO, Jabber and Messenger:
>
> Messenger				MOO
> Jabber
> ---------				---
> ------
> Extensible (SDK)			Extensible (OSS)
> Extensible (OSS)
> Windows/Mac/-Linux		Windows/Mac/Linux
> Windows/Mac/Linux
> Secured with Passport		Integrated security	Modular Security
> options
>
> SASL integration
>
> GSI available
> Server unavailable		Server Open Source	Server Open
> Source
> Integrated with CXP		tkSchmooze!			No
> Multimedia yet
> Deployable (only client)	Deployable
> Deployable
>
> It seems to me that Jabber offers mostly the benefit of providing 80% of
> the MOO functionality (it doesn't currently support topology or the MOO
> style command set), but in a more modern solution. The architecture is
> similar to what we're discussing for 2.0, and again, it's able to
> integrate with our security choice of GT2.0.
>
> Thoughts?
>
> --Ivan
>
> ..........
> Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
> Futures Laboratory .~.  630 252 0920
> Argonne National Laboratory .~. 630 252 6424 Fax
>
>