Yup, I just read through all of the above, and now I'm beginning to think that maybe Jabber shouldn't implement emoticons at all. People send emoticon-containing emails even though plain-text email doesn't support 'em directly; why should IM?
That said, I _would_ ask the transports to translate emoticons if we're going to use any emoticons, because there's no simple way for your client to tell whether [EMAIL PROTECTED] is behind the AIM transport at dave.tj, or whether he's an actual user on the Jabber server aim.dave.tj - saddling the client with such detective work is not only unclean (because it means that the transport is _not_ the only thing that needs to be updated when external networks change), but also quite ugly for the clients (since the transport is in a much better position to figure out what should be translated than the client - especially if we assume that the client knows nothing about the AIM network, which was the general goal behind Jabber in the first place). XHTML is a very easy implementation, because it just treats emoticons as images (which is really what they are). If we're going to start classifying images into different categories, we should probably have a logo standard, so :logo-IBM: should produce an IBM logo image, etc. We can also have an artwork image type, where :art-picasso: would instruct the receiving client to replace that text with a random Picasso painting (in whatever crazy format the device happens to support). Obviously, we shouldn't stop there - having an album-cover image type is absolutely necessary (if we don't want the RIAA to sue our pants off, and then we'll need a special image type for pantless people - maybe :porn: or something like that?), so a client seeing :albumcover-beatles: would have to dig up an image of a Beatles album cover. - Dave David Sutton wrote: > > If I can make a suggestion: > > I would look back at the room logs for the JDEV conference room over > the last week, where there has been many discussions on this topic > looking at many different angles, including a whole evenings worth. Adam > Theo (theoretic.com) has also set up a wiki page discussing this. I'm > noticing some of your ideas are going to get slammed from other > discussions i've been involved it, and it might be best to make sure you > are aware of all the other things that have been said. > > My personal oppinion is that this should be client side only, with > the client doing any of the clever manipulation, as the client knows > what protocol the end user will be using, and I feel that transports > should be simple routers which take a message, encapsulate it in > whichever protocol is necessary, and send it on to the end client. If > you want to come up with some special scheme which will work between > jabber end clients, then fine - just don't then force this scheme onto > messages intended for non-jabber users, as it will be the transport > writers and maintainers who get slated with all the emails about how > transport xyz isn't working as 'it should do' (a purely relative statement) > > Regards, > > David > --- > David Sutton / Peregrine > jid: [EMAIL PROTECTED] > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
