[JDEV] Rich Text in Messages

Wed Dec 20 01:00:24 CST 2000

Dave Smith wrote:
> 
> > > Well, if rich text is so universally essential for a good user experience,
> > > then why isn't it the default message format?  Shouldn't it be?
> >
> > It should be.  There should be a standard syntax and clients should strip
> > anything they don't want to handle.  Session based compression should be used
> > to allow bandwidth to be minimized.
> >
> > sdw
> 
> /me prepares for a fun discussion...
> 
> Clients should not have to know _anything_ about XHTML("rich text") in order
> to display message, IMHO. Hence the <body> tag only contains plain text. If
> you start requring that clients know how to strip out XHTML, you wind up
> requiring that they _know_ about XHTML and hey, presto -- instant client bloat.
> 
> The feature negotiation setup is an interesting approach. I would suggest that
> embedding display/rich text capabilities with the <presence> packet that a client
> sends out would be a good way for this to work..
> 
> In theory, a client could embed extended feature support in its outbound
> <presence> updates:
> 
> <presence>
>       <x xmlns='jabber:x:capabilities'>
>             <xhtml-message/>
>             ...
>       </x>
> </..>
> 
> That would allow other clients to get pushed the proper information -- no
> compliated semantics for request/respond stuff (although that's easy enough
> through <iq>) I just like the concept of having capability information pushed. :)

I agree with this, and have argued for general presence information including
generalized capabilities.  Both have to be completely flexible.  This will
eventually require that asking for presence include filters to avoid getting
too much detail.  I can see that a category system will probably be needed.

xhtml vs. text is a tough call.  Overall, I would say that it's better for a
sending client to look at the remote client capabilities and decide what to
do.  When you consider wireless clients, this approach has a lot of weight
since anything extra for wireless is painful.  This is not optimal if you are
sending one-to-many and clients are mixed, although most systems aren't truly
one-to-many without a broadcast server.  On the other hand, wireless and
similar stripped down clients are likely to have their own gateway in any
case.

Existing systems (AIM) assume that all clients are full-featured.  Jabber is
more diversely extendable however so capability is important to determine
supported features.

Ignoring wireless bandwidth problems, stripping tags is very simple and
doesn't require that a receiver understand everything, only how to drop tags
and unencode <> characters in plaintext.

> D.
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev

sdw
-- 
sdw at lig.net                 sdw at insta.com                 swilliams at Jabber.com
Stephen D. Williams         Insta, Inc./Jabber.Com, Inc./CCI     http://sdw.st
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax  Dec2000