Custom smilies without shortcuts

Marcus Lundblad ml at update.uu.se
Mon Sep 1 15:55:55 EDT 2008


sön 2008-08-31 klockan 18:16 -0600 skrev Peter Saint-Andre:
> Marcus Lundblad wrote:
> 
> > This is the way it works in the MSN protocol.
> > The message itself is sent as the text. Then the smileys are sent as
> > "objects", where the objects are associated with a string.
> > The current implementation in libpurple is oriented in this way too.
> > Theoretically custom smileys on XMPP using XHTML-IM in conjunction with
> > binary objects (XEP-0231) wouldn't need to automatically substitute a
> > shortcut string with an image. But this is the way it is done with the
> > current patch (that I have written) and this is also how it is supported
> > in libpurple (actually GTKIMHTML, the widget that Pidgin uses to display
> > messages), that smileys are added using their strings, kinda like
> > "extending" the default smiley theme.
> > I also think it is good idea that it would work the same way for both
> > XMPP and MSN accounts.
> 
> Hi Marcus,
> 
> Could you provide an example of how this looks in XMPP? Or perhaps work 
> with me to update XEP-0038 along these lines?
> 
Hi

The way it works currently is that the user will have assigned a number
of "shortcuts" to various emoticons.
So when a message is sent and the receiver supports XHTML-IM and
XEP-0231 the occurances of these shortcuts are substituted in the html
body with an <img/> tag where the "alt" attribute is set to that
shortcut. The src will be a cid-based URI according to XEP-0231. Now the
receiver would ask for the data if it hasn't already cached it. 

What Jean La was wondering would be if it would be possible to insert
emoticons without assigning a smiley shortcut. This would ofcourse be
possible using the specification of the XEPs. I'm not sure wether the
"alt" attributes on <img/> is required in XEP-0071, but in that case it
would be possible to auto-generate that string. But the way it will work
in libpurple is probably that it will always be a shortcut associated
with each custom emoticon.

Presently I only cache received data by CID in memory for the running
instance. Further on, implementing a persistent data cache would
probably be a good idea. Since we now have the hash algorithm and hash
in the CID it might make sense to implement a cache based on hash
values. This might make it possible to share cached emoticons between
the protocols that implement similar featurs.

So for this use-case the current specification of XEP-0231 in
conjunction with XHTML-IM works nicely.

The implementation seems to work quite nice, I've even done some interop
testing with the Jabbim developers.

I haven't looked that much at XEP-0038. But I think I remember there
being a discussion about a common format for distributing smiley themes
among various IM clients. The thing that makes it a bit more complicated
is that libpurple-based clients (and Kopete and others) supports
multiple protocols. The proprietary protocols tend to have a fixed set
of smiley codes used by their respective "official" client. Maybe
something based on XEP-0038 might make sense for this.

By the way, XEP-0231 mentions the use for XHTML-IM. In the old
specification there was a use-case for providing a preview in a file
transfer. Would this be added to the new Jingle file transfer XEP,
f.ex.?

//Marcus

> Peter





More information about the Devel mailing list