[JDEV] Rich Text in Messages

[David Waite]

I'm actually for having capability information (and yes, even iq:version
information) sent along with presence. Without this, we are going to have to
have another subscribable resource very similar to keep track of these
capabilities per target resource:

-changes when the resource becomes available/unavailable
-changes when the resource is bumped offline by another resource of the same
name
-changes when the client loads/unloads dynamic modules (for instance, a
whiteboard component)

I would probably also go for a server-side filtering mechanism to ignore
capabilities which you don't care about: for instance a simple applet may not
need to know about markup text, since it only supports plaintext. It does not
need to receive PGP keys for users. It does not need to know what games they
support.

Some of the new client GPG/PGP mechanisms include signed presence and messages.
A nice idea, except for that whole 2KB addition. If you have 300 users in your
roster who all have signed connections, your roster and presence together will
total around 1 MB. Surely I don't want to have a 1 MB transfer when I log in,
especially if it is over a 28.8k modem, even more so if my client doesn't
support GPG/PGP at all.

-David Waite

Thomas Charron wrote:

> From: "Stephen D. Williams" <sdw at lig.net>
> Subject: Re: [JDEV] Rich Text in Messages
> > I strongly disagree.  Presence should include capabilities.  The
> alternative
> > is very inefficient since essentially every user would have to query every
> > other user and this might determine if they wanted to have a conversation
> in
> > the first place.  Imagine that you only spoke Spanish (an alternate
> problem
> > and good placeholder for a desired technical ability, like 'supports GSM
> > audio'), when you enter a group chat or do a directory search, you're
> going to
> > want to filter for other people who have a 'Spanish' capability.
>
>   It really all depends on how you look at a Resource.  Is a Resource a
> different avenue for communications?  Or is it a thing users use to
> designate something they wish?
>
>   Prime example:  Half of the people I've seen using WinJab use /WinJab as
> their resource.  The *OTHER* half, use /Home, /Work, etc..  This becomes an
> issue becouse it means that a given resources capabilities can change
> midstream.  It's interesting food for thought, thats for sure..
>
> > A better example would be that you are looking for someone to participate
> in a
> > multi-user game and need to know who else is also running that game.
> > Insisting on polling for this kind of thing makes the system unusable and
> > unextendable.
>
>   You'd want to end up using the 'browsing' capabilities that have been
> tossed about by Jer, etc.  At that point, you could have a 'registry' of
> sorts, perhaps even the JUD, where you could browse VERY efficiently, so you
> could do one query..  'Show me all users who I may be able to play with'.
>
>   I'm not disagreeing with you on if capabilities should be included with
> presence.  I happen to agree on that, simply trying to look at other methods
> for doing what your examples are about.. :-P
>
> > If the concensus is that plain text is the least common denominator,
> that's
> > not too bad, although it's not 'competitive' with the commercial
> > heavyweights.  Even cell phones have the hardware to do bold or italics
> text.
> > Allowing it to be a capability allows both viewpoints.
>
>     But by standardizing on XHTML, it makes it actually very simple to have
> XSL processors take the XHTML, and reformat it for, say, cell phones, etc.
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev