[JDEV] Rich Text in Messages

Tue Dec 12 16:48:23 CST 2000

After some thought about this, I believe XML is in need of a DIFF analogy.
(I think i've seen stuff called XMLDiff, dunno if it's related).

Anyway, the idea is this:  You have your basic message :  A Dog jumped.
Then, you have ADDITIONAL information to the basic message, such as A <RED>
Dog </RED> jumped.  Rather then recode the entire message, you just use a
DIFF of the two messages.  That allows for complex hierchies with bandwidth
preservation.

  After all, if I get a message of "Love and Peace", and one Schema adds
<CHAPTER> tags, don't send it to me twice, attach a DIFF of the two!  That
way you send me a page of DIFFs rather than another whole friggin book!

Edward

-----Original Message-----
From: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org]On Behalf Of
Thomas Charron
Sent: Tuesday, December 12, 2000 12:24 PM
To: jdev at jabber.org
Subject: Re: [JDEV] Rich Text in Messages

    Very interesting message, brought up many points other may not have
thought of.  Thanks for sending it, brings things to a new light if you
think about it that way..

From: "Todd Bradley" <TBradley at jabber.com>
To: <jdev at jabber.org>
Subject: RE: [JDEV] Rich Text in Messages
> > When you start talking about doubling and tripling the size
> > of a message,
> > you are really just talking about a bandwidth issue. There should be
> > nothing inherent in the Jabber server that hinders it from
> > processing a 300
> > byte message as opposed to a 150 byte message. To send a 300
> > byte message
> > should not require any database queries or other costly
> > operations that
> > sending a 150 byte message would not require.
> I'll take you word for that, since I don't know much about the innards of
> the server.  It just seemed to me that you'd also have twice as much XML
> parsing to do (double your CPU horsepower) and twice as much XML to store
in
> memory (double your RAM).

  It is blatently incorrect in the context it's being used for.  Is you had
a 150 byte message versus a 150 byte message, who's ONLY DIFFERENCE is the
CDATA contained within the body of the message, it's correct, however, in
THIS case, we're talking about additional XML tags.  These tags are gonna
get parsed.  Parsed tags = more memory && more time spent processing them.
Granted, one could come up with schemes to get around the parsing of these
tags by writing a custom parser, all stock parsers currently are going to
parse the tree.  And remember, 150 bytes is what it looks like in text form,
but the psuedo 'DOM' view of things takes up a little more.  And in this
case, the more tags in the message, the more it's gonna take up, and the
more processing time required..

> > I therefore propose this anthithesis to your scenario: How
> > feasible is it
> > to seriously detract from user experience, just because we
> > weren't willing
> > to spend another couple bucks on bandwidth?
> If you can guarantee that this will only cost each Jabber server
> administrator an extra USD$2.00, then it sounds like a good deal.  My
> concern is that two dollars is several orders of magnitude (somewhere
> between 4 and 8, depending on how many users you're serving) too low of an
> estimate.

  I'd say the addition of adding the html tag to *EVER MESSAGE* going thru a
server, it would, at worst, require 5% more power and memory.  There are
alot of other things going on, so I'd say that 5% is a safe estimate on the
number of resources required.

> Say a typical Jabber implementation for internal corporate use is going to
> cost $100,000 by the time you count for my time, a hefty server, extra
> internal (and maybe external) bandwidth, training my users, and
maintaining
> the system.  Of that, the server and bandwidth are probably half.  Let's
say
> there's not a doubling of hardware required, but only a 50% increase.
> That's still $25k.  I'd have a hard time getting another $25k from my boss
> just so my users can send bold text to one another if they want to (and I
> don't even know if they'd use the feature).

  As said prior, I'd estimate 5% power/memory increase.  In the case of a
50k server box, TAKING INTO CONSIDERATION, very incorrectly, that dollar
amount directly corresponds to resources, A 2,500$ increase in requirments.

> I'll admit here that I am biased against rich text messages, though.  I'm
a
> relative newcomer to IM, having only used 3 or 4 systems for about three
> years (not counting Unix talk and IRC).  But even though almost all IM
> systems I've used allowed it, I've never used rich text.  My feeling is
that
> if I'm spending time making my message pretty with colors and fonts and
bold
> and underlines, it's no longer an instant message.  When I'm concerned
about
> appearance and formatting, I'll use email.  But maybe I'm not a typical
> user.  Anyone have any real statistics on what percent of the IM traffic
in
> the world uses rich text?

  No idea, and probrably not measurable.  But you have to bear in mind that
most IM systems *DO* use Rich Text.  Even if your not using the
capabilities, it's using it.

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

  In the case of other IM systems, it pretty much IS to my knowledge.  I
personally belive this should *NOT* be the case in Jabber, but it should
still somehow be supported.  I see it as an optional tag that individuals
can use *IF THEY WISH*.  That way the small percent that wish to use it can.
A client could even say it's only going to send it *IF IT NEEDS TO*.  Aka, a
normal conversation may only consist of perhaps 10% text that needs rich
text..  Like fonts, bolds, etc..

    Any way you look at it, though, you have some darned good points..

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