Verify the actual nick of the connected client.

[relsqui]

We can tell the server what nick we want, but unless I'm missing something we can't tell whether we've gotten it.

[zigdon]

I believe the server will send back a ERR_NICKNAMEINUSE (or one of the
other 43x messages) if we can't get it?
On 1404207268896, Finn Ellis notifications@github.com wrote:

We can tell the server what nick we want, but unless I'm missing something
we can't tell whether we've gotten it.

—
Reply to this email directly or view it on GitHub
#12.

[ayust]

The main question is, what should happen if we don't get the nick we want?

I had left implementing such verification to users of the library for now because I don't think there's a clear single answer to that question. In some cases, it means needing to do some kind of authentication with services; in other cases, it means needing to ghost an old incarnation or otherwise recover the nick, and in yet other cases the right thing to do might be to just exit, or accept the name as given.

Thoughts?

[zigdon]

Could you not just raise an exception, and let the clients deal with it
that way? Right now I think kitn just ignores the error, meaning the
clients have to write more code just to see it.

On Tue Jul 01 2014 at 7:19:22 PM, Amber Yust notifications@github.com
wrote:

The main question is, what should happen if we don't get the nick we want?

I had left implementing such verification to users of the library for now
because I don't think there's a clear single answer to that question. In
some cases, it means needing to do some kind of authentication with
services; in other cases, it means needing to ghost an old incarnation or
otherwise recover the nick, and in yet other cases the right thing to do
might be to just exit, or accept the name as given.

Thoughts?

—
Reply to this email directly or view it on GitHub
#12 (comment).

[relsqui]

Yeah; I don't need you to do something about it, but it would be helpful if you told me so I can. Honestly, it would be sufficient just to have a nick attribute on the client which promises to be the actual nick, not just the one I asked for, and then I can test against it if I care.

[ayust]

@relsqui - that should be the case already (your_client.user.nick); while it's initialized to the nick you request, it's updated from the hostmask provided by the server in its WELCOME message. If that's not the case, then I might need to add some more logic.

[relsqui]

Ah, okay, I didn't notice that. I haven't hit a case that would expose if that doesn't work yet, but if I do and it doesn't I'll let you know.