Hi all,
I’'m implementing a demo of the following - experimental - protocol in Smack:
https://wiki.sch.bme.hu/bin/view/_Munka/JabberCustomSmileys
Basically, we have a message:
“My heart is bleeding for you :(”, and we have to smileys: one aliased as ‘‘heart’’ and one aliased as ‘’:(’’
There’‘s an EmoticonManager (in Spark, I’'ll try to integrate it; for the demo code, is a separate manager-entity), which knows what smileys are in our smiley-collection. Therefore, if it gets a string, only this could give you a set (or list, or collection or whatever you call it) of what smileys are indeed used in a given string (or message).
Therefore, as a part of the rendering of the packetextension of the message, we should get the message body, get the set of smileys used in it from the EmoticonManager, iterate through them, render each smiley accordingly, and then hope that noone will call a “setBody” or anything with the same effect after this.
The problem gets worse, when you have a conversation, and don’‘t want to re-send the metadata of the smileys, not to speak of that you don’'t send the whole thing in case the other part denied it in discovery request (which can be because of lack of implementation, but also because it was disabled in this chat session).
(And there’‘ll be another problem with receiving, since all of the custom-smiley capable clients use a post-rendering mechanism, so the message appears first, then when the requested smiley appears it refreshes, but it’'s client and not protocol specific at least from this point of view)
So, summarized:
-
There’'s a packet extension for message packets
-
It should have a reference of its parent (message) packet (Does it ?)
-
It should have a reference of the current dialog (Does it really ??)
-
Is it guaranteed that after the extension’'s “toXML()” was called, nothing could modify the Message stanza’'s before sending?
-
Any better solutions?
I feel this is violating design standards os smack/jive… 