My outgoing mail reformatter normally does "the right thing." I guess it's having a bad day, today :-(
Fortunately, I think I may know what's wrong ;-) - Dave Dave wrote: > > Julian Fitzell wrote: > > 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 > Okay, so now it's 3 vs. 1 ... you'd think more people would support an > XML-based system for including entities in an XML protocol, rather than > asking clients to do complicated text processing to extract entities :-( > > > 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 > I do need to take it as a personal attack. > > > there doesn't seem to be a lot of support for it in the messages I've > > been reading. > Yeah, Democracy kinda sucks, eh? > > > > > 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. > You simply instruct expat to ignore everything from an open html > tag until the corresponding close tag - a lot simpler than doing an > s/\b:(\w+):\b/\1/g on every incoming message. > > > If you want to do > > this, do it in the xhtml tag where it is only dealt with by clients that > > understand images. > Any client that can do emoticons can do 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. > ...then use relative URLs for your emoticons (and consider having your > client treat incoming URLs as if they were relative, and only fetch the > remote version if you don't have a local version) :-) > > > 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? > Your client can s/.png/.gif/ the URL if you really hate open standards ;-P > Rejecting an open standard (URLs) because some clients refuse to support > open standard image formats is throwing the baby out while leaving the > bath water :-( > > > > > I think the simple solution is to just leave it up to the client (with a > > list of suggested emoticons to support, if desired). > All I can say is "Yuck" :-( > > > This works fine > > except for the weird ones that MSN uses. > MSN has its own problems. If the MSN transport wants to translate > between XML and Microsoftese, that's its own choice, but we shouldn't > let Microsoft make decisions about our open standards. > > > > > 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. > That approach works just fine if we treat emoticons as full-fledged > XML elements. > > > > > 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. > In other words, text clients are an afterthought. . . > > > 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... > ...and in the case of non-English speakers on text clients, all they've > gained is these silly colons before and after words they can't understand > ... I believe the proper gentleman's reaction here should be somewhat > along the lines of "This sucks!" > > > 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. > If we use real XML elements (rather than trying to encode them directly in > the text), their clients can do whatever they want with them (including > the possibility of simply displaying :etoile: or whatever, if they're > working with text-only clients and just can't get over those stupid > colons before and after the words). > > > (but please let's > > not use :luv: - one character saving is not enough for me to stare at > > that all the time) > LOL. . . > > > > > 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. > If we're going to define a seperate namespace for this whole > text-clobbering ordeal, we might as well avoid messing with the actual > text of the message, and use _real_ XML elements to mirror our entities > (emoticons, in this case). > > > 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. > That has nothing to do with our emoticon issue, so let's avoid it here. > (You don't want more discussions here cluttering your inbox, do you? > ...so don't provoke it. . .) > > > > > 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. > LOL ... it's been filling my mailbox, too ;-P > > > > > Returning now to spectator mode. > ...so does that mean it's only 2 vs. 1 now? > > > > > Cheers, > /me likes to cheer, too ;-) > > > > Julian > Dave > > > > > > > -- > > [EMAIL PROTECTED] > > Beta4 Productions (http://www.beta4.com) > > > > _______________________________________________ > > 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
