[JDEV] formatting in messages

[Rob Brown]

At 11:28 PM 9/2/00 -0500, you wrote:
>On Sat, Sep 02, 2000 at 02:49:09PM -0700, Rob Brown wrote:
> > At 04:18 PM 9/2/00 -0500, you wrote:
> > Sending a plain text message in addition to a formatted one seems to be an
> > awkward compromise to keep legacy systems still working, which isn't 
> nearly
> > as necessary in Jabber as it was with email.
>
>Just a quick note here.. clients that don't support XHTML Basic are not 
>"legacy" systems. No client should be forced to support anything more than 
>they don't want to. Think of a CLI client that really has no use for XHTML 
>(perhaps some, but not much).

I agree, and didn't mean to imply that they are, I was talking about what I 
see as the reason html email was done the way it was.

I absolutely agree that the client should not have to support or even know 
about rich text formats.  Instead, a more sophisticated client should have 
to do take the extra step of publishing its extended capabilities.

> > I think it would be better to
> > only send the plain text one *unless* we know the client supports rich
> > text, and then send only the rich text one.
>
>This presents problems. What if I'm offline and you can't "grep" my client 
>to see if I support XHTML Basic? Or probably more likely, what if I'm 
>online with two clients, one that does support XHTML Basic and one that 
>doesn't. Now if I have the XHTML Basic client's resource as a top 
>priority, your client would just send messages to me in XHTML Basic and 
>not have plain text messages. The problem comes in when my XHTML Basic 
>client suddenly goes offline. Now my plain text client is stuck with a 
>blank message that it can't read.

I don't think this is difficult to solve.  You can always have yours set to 
say "always send the plain text no matter what" or at least "if I'm offline 
and you don't know which of my clients you are talking to, always send the 
plain text".

Regardless, plain text should always be the default, and if the sender 
doesn't know for sure that the receiver supports rich text, it should make 
sure it sends the plain text (alone or in addition to other things).

>The point is that we're trying for maximum flexibility.

I guess, in my natural tendency to think of "what kind of cool thing can I 
do", I am seeing the exact opposite.  The assumption that appears to be 
getting made is that there are two and only two types of messages, plain 
text, and semi-rich text (XHTML Basic).  Instead, I see an infinite number 
of "degrees of richness".

As a simple example, lets say I want make an enhanced client that not only 
supports basic XHTML, but also supports a few special tags, like <emoticon 
type="laughing" />.  If I happen to be communicating with someone who uses 
the same client (or another one that supports it), I can easily drop in a 
smiley, or any of a several dozen different variations.  Maybe it would 
even support <emoticon type="custom" src="http://whatever.gif" />

Or, the client may support basic things like bold and italic, but not 
support font faces and background colors.  Maybe it supports embedded 
images (whether the image is sent as an embedded mime type thing, or as 
simply a reference to a url: <img src="http://whatever.gif" />)

Now I suppose you could say, well, if its XHTML it just won't display the 
tags it doesn't understand.  But this means that in composing a message, I 
have no idea how what the receiver is going to see.  I want to know if they 
are going to send my emoticon, or the bold text, or whatever.  If not, I 
can communicate them another way.

I guess my feeling is that maximum flexibility is exactly what client 
developers should have, as they are always thinking of cool new features to 
add.  So I would suggest that in the long term, feature negotiation, rather 
than "duplicate the message in every variation the client could possibly 
support", is a better means toward that end.

Regards,
-rob

>--
>Eliot Landrum
>eliot at landrum.cx
>GnuPG ID: 8F5B499E
>
>-Soli Deo Gloria-