[JDEV] Emoticons: guidelines

[David Sutton]

Hello,

   The thing is that in order to use one of these transports, you must 
have subscribed to it, and the transport will have informed your client 
exactly which protocol it will encapsulate for. Your client, therefore, 
knows exactly which protocol the end client is using.

   In regards to another email (i'm condensing for the sake of peoples 
sanity)

* The transport is not meant to look like another jabber server, it is 
simply a transparent gateway which encapsulates the message in the 
correct protocol necessary (xml for jabber side, whatever for native 
side) and simply relays. The client knows what the protocol the end user 
is using, and thus you only need to add fancy xml tags if you are 
talking to another jabber client. There is no guesswork required.

* I don't like the argument 'well the other network doesn't handle it 
right, so why should we' - we should do better because we can, and 
because this will bring more people over to native jabber if we can 
prove we have these advantages over other protocols. If people can send 
things to us correctly, yet they can't receive the same back, which 
would you feel as a user was the better system. As for sending xml to 
msn, you wouldn't as you know that the transport you are sending through 
is for msn (from when you registered, or you can simply ask it) and thus 
you don't use xhtml or things like that.

* The jabber server does not touch the message, only some of the 
encapsulation the message is being carried in. This is completely 
different to reading and manipulating every message which passes through 
the transport - also think of the additional load on servers which have 
high-usage transports, like jabber.org

Regards,

   David
---
David Sutton / Peregrine
jid: peregrine at jabber.sys.legend.net.uk

--- included message ---
Dave wrote:
> 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 somebody at aim.dave.tj 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: peregrine at jabber.sys.legend.net.uk
>>
>>_______________________________________________
>>jdev mailing list
>>jdev at jabber.org
>>http://mailman.jabber.org/listinfo/jdev
>>
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev