Dave wrote: > Okay, it's a 2 vs. 1 here ... how about if one of you echoes _my_ > messages instead of the other's? That should even things a bit ;-) > > - Dave
If we're going to start counting here, you can put me down for another one against - I don't like sending img tags in the message. But I feel like we're going in circles here. I don't think you need to take it as a personal attack that others are arguing against your proposal... but there doesn't seem to be a lot of support for it in the messages I've been reading. I personally have the following issues with it: 1) I don't like html-ish tags being stuck directly in the message tag... they're hard to filter out if you don't want them. If you want to do this, do it in the xhtml tag where it is only dealt with by clients that understand images. 2) I don't like using filenames to identify an emotion. Some picture that somebody thinks I want to see (maybe some nice porn) does not necessarily convey an emotion to me. I want to learn what an image means in my client. And I want my emoticons to have the same style and a style that matches my UI. And I don't think sending relative paths in the SRC attribute is a good solution to this... one client may not be using .png files so why should it have to look for smiley.png as a key to display it's happyface image? I think the simple solution is to just leave it up to the client (with a list of suggested emoticons to support, if desired). This works fine except for the weird ones that MSN uses. The nicest solution I've seen is the one that allows you to define "(*)" or ":star:" or whatever you want as being a star emoticon (is that really an emoticon? no emotion there... bloody Micros*ft). This gives the following benefits: 1) the MSN transport could add the appropriate tags to messages from the MSN network so Jabber clients could translate it. 2) Jabber clients can use the ":star:" instead which can still be translated by the MSN transport (since it knows ":star:" represents the star emoticon), can be properly displayed (by the end user's preferences) in another graphical Jabber client, and reads in a way that makes sense for text-clients. This also allows you to use :etoile: instead if you are speaking in french. Yes I know it doesn't do the translation for a french speaker talking to an english speaker... but you know what? If it weren't for the system they would have just had to say "etoile" or "star" in text in the first place. (but please let's not use :luv: - one character saving is not enough for me to stare at that all the time) Obvious disadvantage here is bandwidth usage for some clients. This is really an issue of feature negotiation which needs to be resolved by other JEPs. Obviously if you are using an x namespace here then once a feature negotation standard is decided you can query for support of that namespace. But we have the same issue with the double inclusion of an <xhtml> and <message> tag in a message... all these things need to be able to be turned off if we want the protocol so be as small as possible for certain clients. I hope we can return to some constructive discussion. I don't even care much about this issue myself, but I'm getting a little tired of the circular conversation and "you said I said 'foo' but I didn't", "yes you did", etc.... that has been filling my mailbox from this thread. Returning now to spectator mode. Cheers, Julian -- [EMAIL PROTECTED] Beta4 Productions (http://www.beta4.com) _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
