Luke Schierer wrote:
On Sun, Aug 29, 2004 at 04:46:02PM -0700, Nick Sukharev wrote:
  
with reverse engineered protocols, we believe the protocol must be 
considered to be defined by what you can make the official clients do, 
not what just happens to work.  this is good policy for two reasons: 
1)if you depend on a bug and they fix it, you are up a creek for not 
doing it right the first time
2)if you do things the same way the official client does, the admins 
won't notice the difference between your users and their users, and so 
won't care as much about your existance. 

most 3rd party applications don't follow this policy, they define the 
protocol in terms of what they can send to get what they want done, 
never mind if the official client does it entirely differently. we work 
to be interoperable with the official clients, if they did the same, 
we'd be interoperable with them as well, but they follow less strict 
development practices, so sometimes we aren't. that's their problem. 
  
What about the situation when you can easily support these clients without breaking the compatibility with the official ones? After all these 3-rd party clients are sending messages that ARE recognized by the native clients (well, most of the time). If Gaim handles such messages in the same way as the native client does, doesn't that make Game more compatible with the native clients? I would not even try to suggest recognizing messages that are not recognized by the native clients...
  
Considering this the phase "Convince your peers to use Gaim" makes me 
laugh. Should they switch to using ASCII only at the same time? I tried 
a couple of times to convince people to do this. I almost got beaten ;-).

    

that's ignorant and makes me wonder if you have even bothered to read 
anything we have said. unicode supports every possible character in 
every language used today and some that aren't used today. you don't 
have to switch to ascii, you have to talk to people with clients that 
mimic the official ones. 
  
Unicode sounds like a good solution if it is not an offline message. As far as I know, offline messages are not unicode nor they are supported as unicode by the native ICQ client (but they are being sent as unicode by the recent verion of Gaim sometimes).  There are a couple of other things that are not presented as unicode (the ICQ profile information like first/last name for instance.).
on a side note, i could care less if you use gaim. i could care less if 
your friends do. i could care less if ANYONE does. gaim is written 
because we want it. it is provided in the _hopes_ that it will be 
useful, but we aren't paid for this, its a hobby. if no one likes it, 
fine. if its only good for some users, great for those users. if some 
other client is better for you, i'm glad you have that choice. 
  
I noticed that. Anyway, I like Gaim an all I am trying to do is to find some way to help with it myself. I believe most of the gaim developers are on ISO-8859-1 encoding  themselves. As a result, it is very hard for them to even notice most of the issues with other encodings.
The most recent release has a big step in the right direction - it 
introduced the custom encoding for ICQ.
    

yes, because after more than 5 attempts by different people who failed 
to understand that aim is a more used protocol and that breaking aim to 
support this icq-ism isn't acceptable, Mark found some time to write it 
himself. again, this is a hobby, sometimes we have more time than 
others, and we work based on our own priorities, not yours. 

  
Why can't this encoding be used in all places where something is getting 
DECODED instead of ISO-8859-1? This is how all other clients get away 
with their bugs - they just use the default encoding for non-Unicode 
programs in Windows to display stuff.
    

aim uses 3 encodings. it uses ascii, iso-8859-1, and unicode. unicode is 
ideal for all situations, we support iso-8859-1 only because the 
official client does.  we had support for aim first, most of the code 
was written for aim and later icq support was added in. so the 
assumptions are ones that make sense for aim. 

  
It can be made optional if there is a concern that it would break some 
encodings that are not a superset of ASCII. As far as I know, most 
east-European encodings have ASCII as a subset.
    

i'm worried that it will break winaim. make it work with winaim and 
winicq all the time and its good. hacks for something unique to some 
other 3rd party might be standard practice for other projects, but not 
for us. 
  
To aviod breaking winaim we could always use this nice isdigit(username) check. BTW, I am using AIM heavily myself. The last thing I want is to break it.

Thank you,
Nick