Technology Choices: MOO vs Jabber vs Messenger

Ivan R. Judson judson at mcs.anl.gov
Tue Sep 17 22:51:14 CDT 2002


Here are my thoughts currently:

My expectation is that there is a persistent text channel that's
considered "bare minimal node functionality", this enables us to have
users on wap phones and two-way pagers, which is cool.

I know there is some thought to making the text like the audio and
video, which to me means it's somewhat more transient. I don't mind this
particularly, but I'd like two things to be possible:

1) The text should be rich, that is, it should contain enough
information that smart clients can present it smartly, and dumb clients
don't have to know. For this I advocate XML as the text solution. That's
only part of the answer, since XML itself is nothing more than syntax;
it doesn't provide the semantics. So I would think we need to find a
nice XML based solution that (hopefully) provides semantic tools that
can be extended.

2) I think the text channel should be considered an alternate interface
to the objects in the venue. I know this is a bit more than it seems at
first glance, but it would be incredibly powerful if we maintained that
"you can interact entirely via text" ability that MOO provides, but have
the affect being multi-modal. We had this vision in the past, I'd like
to revive it.

3) unicode, ok, don't shoot me. The reality is we have clients all over
the world, it's going to get more real. We have to support language
independence on the client.

These two combined make me consider Jabber, being somewhat familiar with
it. I sit on the software foundation, but that only gives me insight
into the pain of foundation process :-). However it provides a nice
"federated peer-to-peer" model (aka centralized decentralized hybrid per
p2p.com) which shows good efficiency. It supports SASL based security
tools (GT2 is one), so it can be integrated with the security tools
we're using. It has a rich messaging format that's arbitrarily
extensible using a nice namespace solution (so communities can define
their own variants!)

--Ivan

..........
Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
Futures Laboratory .~.  630 252 0920
Argonne National Laboratory .~. 630 252 6424 Fax
 

> -----Original Message-----
> From: Terry Disz [mailto:disz at mcs.anl.gov] 
> Sent: Friday, September 13, 2002 10:50 AM
> To: judson at mcs.anl.gov; 'Ag-Dev at Mcs. Anl. Gov'
> Subject: RE: Technology Choices: MOO vs Jabber vs Messenger
> 
> 
> 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
> >
> >
> 




More information about the ag-dev mailing list