Support for /CODEPAGE

[Szymon Stefanek]

On Monday 01 November 2004 15:59, Paul-Andrew Joseph Miseiko wrote:
> That makes a lot more sense but what happens if a client wants to use
> multiple methods of encoding (perhaps 1 encoding method per channel)?

Well, implementing /CODEPAGE would reduce the client's need to use
mutliple methods of encoding. Clients that can't handle more than one encoding
would be still able to talk to people with different encodings (assuming that
it is possible to map their own encoding to the remote client's one).

Obviously if the client supports utf8 then the problem magically disappears...
but it seems that IRC client developers can't understand that :D

For this reason I suggest to having the encodings on the server to handle
the naive clients and having "utf8" as a default assumption to encourage
developers to use utf8 on the client side too.

> I still think this makes a lot more sense coded into the client and defined
> by the client rather then the server.

The best solution at all would be to have RFC2810 state at the very beginning
in BOLD characters: IRC uses UTF8 encoding and clients *MUST* send utf8 
encoded data.

This would make the assumption that the daemons handle utf8 encoded strings 
and FORCE irc client developers to implement charset mapping on their side.

Since implementing character set mappings is a huge thing (if you don't have a 
library that does it for you), the IRC client developers just ignore the 
problem...(mIrc ignores the problem, for example) and we can't do anything 
about it.

-- 

Szymon Stefanek

------------------------------------------------------------------------------
-
- Somewhere, something incredible is waiting to be known.
-
------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.ircd-hybrid.org/pipermail/hybrid/attachments/20041101/6ffa5f2f/attachment.pgp>