Technology Choices: MOO vs Jabber vs Messenger

Ivan R. Judson judson at mcs.anl.gov
Sat Sep 21 08:42:16 CDT 2002



Some places to start:

http://www.jabber.org/docs/

http://www.jabberstudio.org/

Http://www.jabbercentral.org/

These of course are all one click away from the main jabber page:
http://www.jabber.org/

I'm a member of the Jabber Software Foundation, not sitting on the
council or the board but helping to steer it in reasonable directions.

--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: Rick Stevens [mailto:stevens at mcs.anl.gov] 
> Sent: Friday, September 20, 2002 8:13 PM
> To: judson at mcs.anl.gov; 'Terry Disz'; 'Ag-Dev at Mcs. Anl. Gov'
> Subject: RE: Technology Choices: MOO vs Jabber vs Messenger
> 
> 
> Ivan, what is the best thing I can use to learn about jabber ?
> 
> At 10:51 PM 9/17/2002 -0500, Ivan R. Judson wrote:
> 
> >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