View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004110 | unreal | ircd | public | 2012-05-07 18:41 | 2015-05-18 17:18 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.10-rc1 | ||||
| Fixed in Version | 3.4-alpha1 | ||||
| Summary | 0004110: Extended user information | ||||
| Description | Since we're getting near the limit of parameters and length of the NICK command, I think we need a new command to add more info. I was thinking of some kind of generic command like this: EXTUINFO <nick> <name>=<value> [<name>=<value>] Like: EXTUINFO Syzop sslfp=123456789etc somemore=.... and so on Then other servers can broadcast this message to the rest (except towards sender, as usual), and even if we add more fields to the user struct later you don't have any problems with distribution and so on. The alternative is to stay with classic IRC and just do: EXTUINFO <nick> <value1> and then in a later release when you add a new param / value EXTUINFO <nick> <value1> <value2> Or add a: SOMECMDFORPARAM1 <nick> <value> which is also something common. However the 1st method is more flexible, and I think better: it doesn't need full PROTOCTL negotiation (like for every upgrade of the NICK command). Also if you only want to change 1 property of the user (struct), then you don't need to send the whole line. I'm not suggesting to move all kinds of current traffic into this, just for extending stuff (new fields, or fields that are currently not global). | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I'd agree the first method is best, not to mention it can be used as a "meta data" command then too. And as long as the server supports the command, it doesn't necessarily have to know what to do with the data other then store it or pass it on which unlike the current expanding NICK message option is more future proof too. And my thoughts are Unreal would store any key=value pairs it doesn't have pre-defined uses for in effectively a dictionary like storage. |
|
|
charybdis has a fairly decent splay-tree dictionary that we can yank for this. EXTUINFO should only be used for updating data that does not need to be atomically done though, as there is a race condition. So things like ESVID should stay as part of the NICK/UID command. |
|
|
i am going to work on this a bit in the next few days, as i want to get certfp stuff in. |
|
|
Great, thanks :) I don't think I'll have much time for UnrealIRCd upcoming months, so any contributions are very much welcomed. It may take some time for me to go through patches and approve them, but as said they are much appreciated. |
|
|
The way I have thought of doing it is: EXTUINFO <nick> <key> <value> This is similar to InspIRCd's metadata command, so parsing is cheap and easy at the expense of more bandwidth in the initial burst (but that isn't a huge problem anyway.) |
|
|
yes, that would be fine. not support setting multiple key / value pairs in one command. then we don't have to worry about spaces in values either. I think we're on the same page regarding server to server bandwidth in general: nowadays bandwidth is rarely a problem, and if someone has worries about it they should use zip links. |
|
|
unreal-splaytree-core.patch implements the core dictionary store, this is pushed to my branch on bitbucket. |
|
|
Ok. Just to let you know I did notice the patch when you added it (changed status), but was actually waiting for something to use this, before I commit. So, when EXTUINFO is implemented (has a patch), then I'll commit both :) As for the splaytree patch, is this used in other projects (I see charybdis?), and proven to be stable? Just asking.. as it's too much for me to read. |
|
|
undid the 'has patch' status until the issue has a new patch according to my latest post. |
|
|
The ModData system was committed.. I don't know.. a year ago or more.. and provides this functionality. The system has recently been improved post-3.4-alpha1 and will be documented soon. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-05-07 18:41 | syzop | New Issue | |
| 2012-05-07 18:42 | syzop | Relationship added | related to 0004020 |
| 2012-05-10 18:28 | Jobe | Note Added: 0016996 | |
| 2012-05-11 12:05 |
|
Note Added: 0017000 | |
| 2012-05-29 23:03 |
|
Note Added: 0017011 | |
| 2012-06-02 20:39 | syzop | Note Added: 0017012 | |
| 2012-06-02 20:41 | syzop | Note Edited: 0017012 | |
| 2012-06-09 09:15 |
|
Note Added: 0017019 | |
| 2012-06-09 10:07 | syzop | Note Added: 0017020 | |
| 2012-06-26 05:20 |
|
Status | new => has patch |
| 2012-06-26 05:20 |
|
File Added: unreal-splaytree-core.patch | |
| 2012-06-26 05:21 |
|
Note Added: 0017027 | |
| 2012-08-17 10:13 | syzop | Note Added: 0017068 | |
| 2012-08-17 12:36 | syzop | Note Added: 0017075 | |
| 2012-08-17 12:36 | syzop | Status | has patch => acknowledged |
| 2013-05-26 10:56 | syzop | Relationship added | related to 0004217 |
| 2014-06-01 11:46 | syzop | Assigned To | => syzop |
| 2014-06-01 11:46 | syzop | Status | acknowledged => assigned |
| 2015-05-18 17:18 | syzop | Note Added: 0018314 | |
| 2015-05-18 17:18 | syzop | Status | assigned => resolved |
| 2015-05-18 17:18 | syzop | Fixed in Version | => 3.4-alpha1 |
| 2015-05-18 17:18 | syzop | Resolution | open => fixed |
