[JDEV] Emoticons: guidelines

[Dave]

Reply inline:

 - Dave

David Sutton wrote:
> 
> 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.
Well, your client knows the ID string of the transport, so I guess it
_can_ figure out what protocol the end client is using if it happens to
know what protocol the network that "MSN Transport" connects to uses.
Saddling the client with this requirement just so it can support emoticons
doesn't seem to me like the correct solution.  It's basically saying to
the client that the Jabber server infrastructure won't really support
foreign IM systems; it'll just route the raw data part of the message
between you and the foreign IM system, and let you break your head trying
to figure out how to translate to/from that IM system's protocol.  Now,
when the foreign IM system changes its protocol, you don't just have
to update the transport - you also have to update every client that
"supports" that foreign IM system.  When you want to add a transport for
a new network, you have to update every client to support the conventions
used by that network.  This sounds an awful lot like what Trillian has
to contend with.  I think I'd rather just use Trillian whenever it gets
around to supporting Jabber as one of its IM systems, because using
other IM systems through Jabber won't give me all of the advantages it
claimed to.

> 
>    In regards to another email (i'm condensing for the sake of peoples 
> sanity)
People shouldn't be sane.  If you're trying to make people sane, you
ought to be lynched ;-P

> 
> * 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.
...but the transport becomes not-so-transparent anymore :-(

> 
> * 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.
That's why we should use a proper XML approach, or at least borrow some
tags from HTML.  Plain text is not handling it right, no matter how you
slice it.

> 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.
Please see my comment above about transport transparency (or lack
thereof).

> 
> * 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
Point taken ... I know ... I was just attempting to address an emotional
concern, and for emotional concern purposes, the Jabber server already
has complete control over your messages.  It can just as easily replace
"black" with "white" if it really wants, and the user can't do a darned
thing about it (except boycott the server).  "Allowing" the server to
translate emoticons so they actually make sense to the recipient doesn't
seem like much of a stretch, if you ask me.
BTW - The Jabber server _does_ translate between encodings (since it's
supposed to send each client data in the character set that it requested,
IIRC), right?

> 
> Regards,
same to you,

> 
>    David
Dave

> ---
> 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
> 
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>