You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a relatively small and self-contained task. So, I think it'd be a good first issue for anyone looking for a way to contribute! This should be contributed as part of 0.14.
Currently, Message is defined to use a String for prefixes, but in RFC 2812, the grammar for prefixes is given as prefix = servername / ( nickname [ [ "!" user ] "@" host ] ) which is sufficiently specific to allow for parsing them into an enumeration instead.
One problem is that in the (probably rare in practice) situation where you are receiving a nickname without a username or hostname attached, there is ambiguity. Most nicknames are also valid server names. However, I think it would be reasonable to classify anything containing a . as a server name and anything else as a nick name. Otherwise, we could add a third option for Ambiguous, but that probably punishes the common case for something that I'm not sure even happens on modern IRCds.
Ramifications
Part of the Message API has some functionality for getting the source nickname and so forth. This API should be cleaned up using this new enum.
The text was updated successfully, but these errors were encountered:
This is a relatively small and self-contained task. So, I think it'd be a good first issue for anyone looking for a way to contribute! This should be contributed as part of
0.14
.Currently,
Message
is defined to use aString
for prefixes, but in RFC 2812, the grammar for prefixes is given asprefix = servername / ( nickname [ [ "!" user ] "@" host ] )
which is sufficiently specific to allow for parsing them into an enumeration instead.This should be probably look something like:
One problem is that in the (probably rare in practice) situation where you are receiving a nickname without a username or hostname attached, there is ambiguity. Most nicknames are also valid server names. However, I think it would be reasonable to classify anything containing a
.
as a server name and anything else as a nick name. Otherwise, we could add a third option forAmbiguous
, but that probably punishes the common case for something that I'm not sure even happens on modern IRCds.Ramifications
Part of the
Message
API has some functionality for getting the source nickname and so forth. This API should be cleaned up using this new enum.The text was updated successfully, but these errors were encountered: