Moo supports 8 bit text. So should lily.

Well, when you enable binary strings on a connection (which we'd do with an #$# option), the way in which moo parses user input changes. A new verb needs to be implemented to make these binary strings get handled in the same way normal lily connections are as far as input goes. (perhaps chunk up the input, and hand it off on newline boundaries.)

Also, there is a problem with users with binary enabled talking to users with 7-bit connections. Sends going from 7 to 8 should be unaffected, but going from 8 to 7 will need to be massaged in some fashion. (perhaps a user settable option, if there is more than one sane way to do this.). Garance has expressed concern about users spoofing server information with this mechanism, so any solution will need to address this issue.

In addition to the content of messages, I think all strings should be allowed to be 8-bit : user names, discussion names, memos, etc.

Finally, even though users can pass around 8 bit data with impunity, there is an issue regarding encodings - you want to make sure that whatever you send is viewed as you'd expect. ChrisParker mentioned this in a private conversation on lily a while back. I am not a unicode expert, but I would expect that we need to be pointing in that direction. UTF-8 was explicitly mentioned. =-)

-- CoKe - 11 Aug 2003

Some testing has shown that if you have one user on a standard (7-bit) connection, and another on a new binary (8-bit) connection, then you have to do some checking for traffic going in EITHER direction. People on a 7-bit connection can still send binary strings (including embedded newlines) to the 8-bit connection, if they just read a little on how the MOO language does binary encoding. That is because internally the MOO is still using only printable characters in all its strings. The "binary" switch only effects whether the moo does a character-set conversion when writing those strings to a client.

-- GaranceDrosehn - 11 Aug 2003
to top