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