Re: [dcplusplus-devel] LinuxDC++: Fixes a nick encoding issue that could cause transfers to fail

[Jacek S. <arn...@gm...>]

Steven Sheehy wrote:
snip

> The attached patch solves this in the following way. First, the peer
> nick is
> stored on the list of expected connections in ACP, not in uft-8. This is
> not
> a problem, because the stored nick is just a key and is not used for any
> other purpose. Next, when UserConnection::on() receives $MyNick it is
> passed
> further untranslated. Peer's nick gets translated to utf-8 later inside
> ConnectionManager::on(MyNick) when it becomes possible to determine and set
> the correct encoding.
> 
> This all can be seen directly from the patch, of course. Perhaps, a better
> way of doing things could be to separate incomming connection checking from
> ConnectionManager::on(MyNick) and put it in UserConnection::on() or do
> something similar.
> 
I guess this is ok...at some point maybe it would make sense to store the non-utf8 nick somewhere
when it first arrives from the hub and use that always without encoding back and forth to utf-8
since some round-trip conversions may be lossy (or rather, might not yield the same byte
sequence)...expectedConn would probably have to keep a UserPtr reference at that point along with
the expected byte sequence...Then encoding and possibly huburl could go away from userconnection I
think and it would be correct from an encoding-point-of-view, and the cid wouldn't have to be
synthesized in connectionmanager since we'd already have a userptr...

/J