View Issue Details

IDProjectCategoryView StatusLast Update
0004110unrealircdpublic2015-05-18 17:18
ReportersyzopAssigned Tosyzop 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Product Version3.2.10-rc1 
Target VersionFixed in Version3.4-alpha1 
Summary0004110: Extended user information
DescriptionSince 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).
TagsNo tags attached.
3rd party modules

Relationships

related to 0004020 resolvedsyzop SSL Client Certificate Fingerprint Command 
related to 0004217 closedsyzop Unreal 3.4: Modulize user/channel modes 

Activities

Jobe1986

2012-05-10 18:28

reporter   ~0016996

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.

nenolod

2012-05-11 12:05

reporter   ~0017000

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.

nenolod

2012-05-29 23:03

reporter   ~0017011

i am going to work on this a bit in the next few days, as i want to get certfp stuff in.

syzop

2012-06-02 20:39

administrator   ~0017012

Last edited: 2012-06-02 20:41

View 2 revisions

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.

nenolod

2012-06-09 09:15

reporter   ~0017019

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.)

syzop

2012-06-09 10:07

administrator   ~0017020

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.

nenolod

2012-06-26 05:21

reporter   ~0017027

unreal-splaytree-core.patch implements the core dictionary store, this is pushed to my branch on bitbucket.

syzop

2012-08-17 10:13

administrator   ~0017068

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.

syzop

2012-08-17 12:36

administrator   ~0017075

undid the 'has patch' status until the issue has a new patch according to my latest post.

syzop

2015-05-18 17:18

administrator   ~0018314

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.

Issue History

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 Jobe1986 Note Added: 0016996
2012-05-11 12:05 nenolod Note Added: 0017000
2012-05-29 23:03 nenolod Note Added: 0017011
2012-06-02 20:39 syzop Note Added: 0017012
2012-06-02 20:41 syzop Note Edited: 0017012 View Revisions
2012-06-09 09:15 nenolod Note Added: 0017019
2012-06-09 10:07 syzop Note Added: 0017020
2012-06-26 05:20 nenolod Status new => has patch
2012-06-26 05:20 nenolod File Added: unreal-splaytree-core.patch
2012-06-26 05:21 nenolod 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