Technology Choices: MOO vs Jabber vs Messenger

Wed Sep 18 07:47:02 CDT 2002

Does the jabber's multiple-server model fit with the AG as we're thinking 
about it now (offhand it seems like it does, would you site a jabber server 
coincidental with the venue service providers?

Do the jabber servers have a notion of user accounts, or could it use the 
venues mechanisms natively?

--bob

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
> > >
> > >
> >