[standards-jig] spring cleaning!
thoutbeckers at splendo.com
Tue Apr 22 14:52:32 UTC 2003
"Peter Millard" <me at pgmillard.com> wrote on 22-4-2003 1:37:39:
>> - 38 (Icon Styles) -- some controversy in the Council over this
>I still have serious issues w/ -38. I'd like to see this JEP turn into
>something which just defines _STANDARD_ emtoticons for jabber, and be
>done with it.
At the time I suggested the definition of a "core" set of emoticons.
The discussion was still ongoing but PSA threatend to kick us all of
the list if we made any more postings about it :) Adam Theo decided to
take a different approach with JEP-0038. It looks very decent by now
though, and is surthenly a usefull tool for client developers.
It's not too late to unify the two approaches though, my suggestions:
- Add an extra element to the .jisp format. Besides <name/> also
include something like <set/>. A set would be defined as a group of
emoticons with a surthen meaning. For example :-) = happy , :-( = sad,
>:-) = evil, etc. So there can be different implementations of a "set",
>that all have a different "name" and use different icons, but that are
>interoperateable. So if I like yellow emoticons, and you like red
>ones, we can use different ".jisp" files in our clients, but since
>they implement the same "set" we still make sense to each other.
- Make it possible to use DISCO to find out wich set(s) the other
- Agree on a "core" set in the JEP that all clients are recommended to
have a ".jisp" for.
Since the JEP now also covers inter-client communications include my
- include a way to flag that a message does not want to be parsed for
emoticons, or maybe even only specific parts of the message.
- include a way to target a message at a specific "set".
- Allow one .jisp to cover more then one "set" (by including multiple
- Set up a registration point (JANA?) to prevent conflicting sets that
want to use the same set name.
- Sets that have a different set-name but "claim" the same emoticon
characters. Not a problem if a specific set is targeted in the message.
If that is not the case, problem could be made less of a problem by
(for example) a unicode-style registration of emoticons. However, what
the chance of such a problem occuring and it having a very serious
impact on the user-experiance?
- Something I'm missing?
I think this way we can have the best of both worlds.
Simple clients (with no DISCO suopport for example) can still just use .
jisp files that support at least core (or give a warning if it does
not). Even simpeler clients wich don't want to support .jisp files can
just hardcode an implementation of the "core" set, and optionally other
Advanced clients can use all the emoticons they want amongst each other
knowing the other client supports it (using DISCO to check), and the
emoticons can still be customized.
And clients can still use the interoperatable .jisp file format, so
more content for them, and no reinventing the wheel there :)
>> - 41 (Jidlink) -- how does this relate to 65 and 47? retract?
>This doesn't seem to be useful in a world in which -65 exists (and is
>Draft). Needs to be retracted or rejected IMO.
Jidlink can be seen as a generic connection initiator (it could be
extended to include, and make the distinction between different kinds
of connections,eg. reliable, unreliable, encrypted, etc.). In other
words, it does something completly different as JEP-0065. It conflicts
more with JEP-0052 (filetransfer). If there will be such a thing as
Jidlink, you should be able to use it inside this JEP (where currently
feature-negotiation is used directly).
Software Engineer @ Splendo
More information about the Standards