Your solution does not allow the sending clint to disable the
formatting options, keeping the user from wasting time with formatting
that will never be received.
On 7/6/07, Daniel Noll <[EMAIL PROTECTED]> wrote:
On Friday 06 July 2007 08:31, Rachel Blackman wrote:
> It's useful to know whether or not another client supports XHTML-IM
> before you send them a large packet filled with both plaintext and
> XHTML data. (Especially for the oft-cited case of mobile folks who
> pay by the megabyte.)
This particular problem has a more elegant solution that works without
either
end needing to know what the other supports.
1. Client running on the mobile somehow asks the server to strip XHTML
bodies out of messages.
2. Client running on the mobile simply doesn't send XHTML.
Problem solved without caps. And interestingly, this solves another case of
a
naive client which doesn't even check if the recipient supports XHTML bodies
before sending XHTML. :-)
> Further, in order for PEP to work for capabilities, you'd really need
> to /require/ every client to publish their disco capabilities as a
> PEP item, and also require everyone to subscribe to that item for all
> those on their roster. That's a heavy set of requirements just to
> discover support for file transfer or formatted text! Plus, it
> generates a lot of text; no matter how many people on your list use
> 'Pidgin 2.0' you will get the entire disco result for each of them as
> they log on.
And ironically due to the size of the XML which wraps around a pubsub
message,
the flood will probably be even larger than the original disco flood! :-D
...
> Which basically brings us back to XEP-0115. :)
Indeed.
But mobile client users and authors are still going to object to receiving
data they didn't ask for, especially if it's the same size as what was
already being sent in the presence. :-)
The way I see it, they have two options.
1. A gateway that strips it out. Not a bad idea as it can strip out loads
of other things they don't need. Like, oddly enough, XHTML bodies from
clients which didn't check the caps beforehand. ;-) Or perhaps even
messages and presence from people they don't want to come to their
phone.
Or, maybe it even reduces the stream to a much more compact binary
protocol with less extensibility.
2. We add some kind of opt-out <iq/> that you send before becoming
available, which says "no caps, please."
Daniel
--
Joe Hildebrand
