View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005330||unreal||ircd||public||2019-07-13 15:45||2019-10-05 19:14|
|Target Version||Fixed in Version||5.0.0-alpha4|
|Summary||0005330: finish labeled-response implementation|
|Description||I did start a labeled-response implementation when starting on U5 dev back in April.|
It still needs to be improved to become an acceptable/workable implementation, in particular if there are already tags in the message (easy) and if there already is a BATCH involved (more serious work)
Oh and update it now that IRCv3 has decided what to do with 0 length responses. The current draft spec is here https://github.com/ircv3/ircv3-specifications/blob/master/extensions/labeled-response.md
Since it's an experimental feature, I'm going to work on other things first, that have a higher priority.
|Tags||No tags attached.|
|3rd party modules|
It mostly works right now, but will always issue a BATCH (except for emtpy replies, in which case it will issue an ACK). I'm sure there are corner issues, in fact there are some TODO/FIXME's spread around the source and on my list. But the basic idea is there. My last commit summarizes the current status and plans:
Author: Bram Matthys <firstname.lastname@example.org>
Date: Sun Aug 18 09:24:43 2019 +0200
Enough updates on labeled-response and echo-message for today.
Note that the labeled-response implementation currently requires
'batch' and will always start a BATCH if there is any response.
Later on we can implement a simple queue so we don't have to
start a batch for 1-line responses (which works, but looks a bit
silly if you look at raw server traffic). That may be after alpha1,
though, as there are more (important) things to work on right now.
Done. No longer using BATCH all the time, so we have 3 variations:
0 response: ACK
1 response: @label=xxx in the reply
2 or more responses: use BATCH
Also nested batches work (eg: chathistory on join + label).
I even added support for labeled-response in LIST, which took some extra effort since this gets called in an event loop every x seconds.
|2019-07-13 15:45||syzop||New Issue|
|2019-07-13 15:45||syzop||Status||new => assigned|
|2019-07-13 15:45||syzop||Assigned To||=> syzop|
|2019-07-13 15:45||syzop||Relationship added||child of 0005279|
|2019-07-13 15:45||syzop||Relationship added||child of 0005280|
|2019-08-18 15:17||syzop||View Status||private => public|
|2019-08-18 15:20||syzop||Note Added: 0020821|
|2019-08-18 15:21||syzop||Note Edited: 0020821||View Revisions|
|2019-10-05 19:14||syzop||Status||assigned => resolved|
|2019-10-05 19:14||syzop||Resolution||open => fixed|
|2019-10-05 19:14||syzop||Fixed in Version||=> 5.0.0-alpha4|
|2019-10-05 19:14||syzop||Note Added: 0020931|