Give EnDroid font capabilities, for sending richer text.

Martin has a hacked up EnDroid that is capable of sending the requisite coloured message.

Difficulty is in integrating this cleanly via EnDroid APIs, given it requires low level fiddling with XML Elements.

Proposal is to provide:
 - A more generic send() method on self.messages. This will accept a domish.Element, and keyword arguments to determine whether it sends a <message> or an <iq>
 - An equivalent on Message for sending a reply() using XHTML-IM
 - A plugin that provides helper methods for creating (simple) XHTML-IM messages. This could mean parsing HTML input, parsing some other syntax, a functional (but non-DOM) method for building up messages, or something else. Intention isn't to replicate all capabilities of the DOM approach, but provide a simpler interface to folks who just want to say "DON'T PANIC", but in large friendly red letters.

--------------------------

So... this is Simon. Not sure of the best way of recording a conversation here, so I'll just tag on the end for now. I've been playing around with this and have a somewhat different opinion.

First, it seems preferable to me to put XHTML-IM down close to the Wokkel layer rather than up near the plugins. I suspect the right thing to do is actually to put a live wokkel in the repo, patch it, and contribute changes upstream. But as it happens, it's very simple to patch in what we need, so that's what's in my branch. The core capability there is that plugins can set 'msg.html' as well as 'msg.body' if they like (same with callbacks like msg.reply) and if the html attribute is present, it gets put in the XML DOM correctly on the way out.

Second, I don't think there's much win in providing an EnDroid-specific HTML construction layer. This is partly because that's a well-known problem that isn't to do with XMPP. But mostly because it turns out that XHTML-IM mostly sucks. With Pidgin as an example, the only things I've been able to do universally that are actually useful are:

 - anchors (ie hyperlinks)
 - use bold and italics (either using <b> and <i> or font-weight:bold/font-style:italic inside <span class="..."> so long as you do <p><span style="..."> rather than just <p style="...">)
 - newlines (ie parity with plain-text) - note that "<br />" is better-behaved than "<p>...</p>"
 - images (more below)

It is possible to get a mono-space font if you're specific (eg <span style="font-family:Courier">) but the default Adium client settings are to ignore font family and font color that come from XHTML-IM.

Even if you enable this, then font color is... interesting. If you set "color:red", you get cyan. If you set "color:cyan" you get a sort of purple. Pidgin on Windows doesn't suffer from this, so you can set the foreground text color at least.

So to be honest, unless I'm missing how to unlock lots of multimedia goodness out of pidgin (which is possible) this is basically a way of getting bold and italics. In which case, you might as well just use <b> and <i>, and plugins can construct that themselves without any help.

In general, plugins are responsible for providing both the plaintext msg.body and msg.html if they want html. But if they're mostly just providing a bit of markup, then they should be able to just provide the html variant, and have this stripped down to plaintext on the way out. There's a primitive version of this in my branch. If people agree this is the way to go, then we should refine the internal API a bit, since it used to be that 'body' was the one thing every plugin supplied, and if that's no longer the case, you end up with lots of code like msg.reply(None, "That <b>None</b> is where the plaintext used to go, but now we don't care"). In addition, plugins still currently need to provide a <p> wrapper in the html, and there isn't a simple way of building up multi-line strings (as would be useful for the help plugin, for example). So if people agree this is the way to go, we can tweak this all a bit to make the plugins' life a bit easier.

Finally, the idea of losing out on big friendly "DON'T PANIC" letters was just too sad, so as a consolation prize I implemented XEP-0231, which seemed to be what Pidgin wanted in order to display HTML inline images. Anything bigger than 8kb is not guaranteed by the spec, and also seemed to provoke aggressive shaping by ejabberd, but this is enough to get something useful. The generic XEP-0231 support seems easily solid enough for plugins to generate and serve little inline graphs and the like.