[standards-jig] Jabber Icons (JEP-0038)
theo at theoretic.com
Thu Jul 18 02:38:45 UTC 2002
Peter Saint-Andre wrote:
> I've received and published a new JEP from Adam Theo regarding emoticons
> and "genicons". Before you dismiss it out of hand because you think the
> topic is trivial, I must say I think Adam has performed a valuable public
> service by putting this together even though emoticons is not his favorite
> topic. You can find the JEP here:
> Is this JEP a serious proposal or a quick writeup of ideas?
Yes, it is meant as a serious proposal. It is in final draft, just
soliciting feedback from the community before going on to the Council.
> Why only support PNG? Is there a _serious_ reason for this?
> What about MNG? JPG? GIF? etc.
Iain Shigeoka wrote:
> Yes, since Jabber is fully committed to XML it makes sense to support
> SVG. Even on platforms where SVG is not supported there are free tools
> available for converting SVG to raster formats (Batik from Apache for
> example). I'd put my vote in for making the standard SVG and letting
> implementations either find an SVG renderer or SVG to raster filter.
I chose PNG in the JEP because it was the only open and widely supported
graphic format that I knew of. Now that SVG seems to be widely supported
too (I'd like to make sure of this, though. Anyone have some info or
links for me?), I'm thinking about using that instead (or should SVG be
in addition to PNG?).
Also, what is MNG? Never heard of it before. Is it open and widely
Christopher Josephes wrote:
> On a side-note, why limit sound choices to WAV files??
Is there a better open format for sound clips that has wide support on
> How does one client retrieve the iconset that is being used by
> another person? Or should someone's own iconset be used even to
> display icons in incoming messages?
Correct, only icon styles installed on the receiver's own client are
used. So if someone has an icon style that turns a @->-- into a rose,
and they sent me a message with that in it, I would need to have an icon
style installed that also did something to that text string, or else I
would just see the text as-is.
This is done to keep the specification simple. CBas also brought up to
me OOB the idea of having the sender include a list of icon styles they
are using, for the opportunity of the receiving client to somehow fetch
and install the styles on-the-fly, or at least let the receiver know
that the sender intended it to be viewed with certain icon styles.
* How would icon styles be uniquely identified and referenced since
anyone can create their own icon style? Possible solution is to use a
hashing algorithm on the package.
* How would receiving clients automatically find these styles? There
would need to be some universal network of these icon styles which
clients could connect to in order to get the intended styles.
Overall, I like the idea of at least allowing senders to suggest the
icon styles by sending what icon styles they themselves are using at the
time. But the technology behind such a mechanism would be great, much
greater than I had intended for this spec. It would require a repository
of hashes of the icon style packages, as well as archiving of the
packages themselves. That's a big undertaking. In the end, I'm going to
say it should be kept for a future date. The best I can do right now is
to make sure the current spec does not prevent that from happenening in
any way in the future, which I think it thankfully does not. I wouldn't
mind seeing a future JEP that creates such a network of icon style
packages for automatic querying and download, but now is not the time
since it would likely not be implimented any time soon.
> Where are the example icon sets?
Currently I do not have any fully created. I give an example of an
icondef.xml file as well as explain the hierarchy and structure of an
icon style package. Hopefully that will be enough for people to start
making icon styles.
> What kind of MIME-type or file extension should be used?
I had not thought of using MIME types and special extensions to allow
web browsers to pass the icon style packages along to the Jabber IM
client for automatic installation. That is a good idea. Do you think I
should cover it in this JEP since I don't imagine it taking up much
space or complexity? Or leave it for the future when we may be better
equipped to actually impliment it?
Jim Ray wrote:
> My first comment is that a complete list of emoticons/genicons
> should be agreed upon. That way the themes all implement the same
> things. This would eliminate having to rank icon sets.
I disagree (naturally). I created the spec to allow users to define
their own text strings for icons because I'm sure that will be a major
selling point of the spec to end users. The ability to come up with new
and creative text strings and then easily get your favorite client to
recognize it and turn it into a desired graphic and sound is a big plus,
IMO. Now, I understand the need for a core set for transports and basic
clients to use, as well as a starting point for icon style developers to
use. Therefore I included a list of reccomended icons in Section 4 of
the JEP. I hope I was not unclear about its purpose being there.
I hope that covers the ideas expressed here. Any others? I'm open to
making changes to the JEP now, since now is better than later.
/\ Adam Theo, Age 23, Tallahassee FL USA
//\\ Email & Jabber: theo at theoretic.com
// \\ (Boycotting AOL, therefore no AIM or ICQ)
// || \\ Theoretic Solutions: http://www.theoretic.com
|| "Building Ideas by Bringing them Together"
|| Jabber Protocol: http://www.jabber.org
|| "The Next Generation Communications Protocol"
|| "A Free-Market Socialist Patriotic American Buddhist"
More information about the Standards