[Standards] Re: Inband Images
jig at monitzer.com
Wed Mar 28 20:56:49 UTC 2007
On Mar 28, 2007, at 22:21, Ian Paterson wrote:
> Yes, the data: URI protocol is only supported by the Firefox and
> Opera browser rendering engines. So Web clients could only support
> Inband Images if the client is opened inside one of those two
I just had an idea: Maybe the web client could convert them to
regular images on the fly? The sender wouldn't notice anything.
That's more like a workaround, but it could work.
On Mar 28, 2007, at 20:33, Adam Nemeth wrote:
> I'm writing a university paper about MSN custom emoticon handling in
> jabber - I know, I know, MSN is propiertary etc, but teens doesn't use
> anything other in Hungary only _because_ nothing else handles this. If
> needed we had social research papers somewhere about this.
Adium also had lots of requests for this (receiving custom emoticons
works right now).
> You can look at my proposal on:
This sounds to me like it's way too complicated, esp. the conflict
handling. I think those emoticons should look like this in the xhtml:
<body>Hello! <img src="data:..." alt=":-)"/></body>
While it should just be "Hello! :-)" in the plain text version. This
would limit emoticons to xhtml-capable clients, but I don't have an
issue with that (since the client would have to be able to mix text
and images anyways). xhtml-capable clients without image capabilities
could just display the text version of the image (which they should
do now anyways).
Larger images would use an approach similar to the one used in HTML
mails, the message packet would also include a hash to avoid doing
the same file transfer multiple times.
Keep in mind that file transfers take 1-2sec to set up best case, so
it should be avoided at all cost.
> Now T-Online will introduce jabber in their webmail for 3 million
> users at the end of this month. The internet penetration is about 42%,
> which means, practically anyone in Hungary will have at least one
> jabber address. This is worth to work on it.
> What we need:
> - Full, "transparent" support of MSN gateways with all of these
> nifty features
That's outside of the XMPP standard, this should be handled by the
gateway. I don't think any of the ideas here would be inherently
incompatible with the MSN solution (note that I've never used MSN
> - A good client with good speed and minimal resource consumption
> for windows
> - Possibly a webclient which can do the same.
Well, there are a few projects working on that. I applied for
enhancing the XMPP-support in the Adium client in SoC 2007, so I
could add anything we can come up with (as long as it's not using
jingle) to it if I get accepted.
More information about the Standards