[ticker-dev] Reply-To and Reply-From

[Ian Lister]

Hi all,

Protocol development seems to have been stagnant for a while, but I'd like 
to propose a couple of new attributes related to cross-channel threading 
that I think would be useful. This might be a bit contentious because I 
know not everybody believes in cross-channel threading, but I see it and 
use it frequently (and find it useful) and think it could be made even 
more useful if these attributes are widely adopted.

There are two main situations in which cross-channel threading is used 
that I've seen. The first is when a conversation starts on one topic and 
then meanders (or branches) off onto another topic that is more 
appropriate in a different group. This is frequently a conversation moving 
(in either direction) between technical work and casual chat or between 
different fields of work.

The other common situation is producers that essentially have their own 
group but may trigger discussion that is best done in another group. For 
example we have cvs2ticker set up to report all CVS commits to a "cvs" 
group, but that may trigger discussion about the merits of that particular 
patch, more work that needs to be done or other related technical issues, 
all of which is better done in the "dev" group. Similarly our automated 
builds generate a notification to the "build" group but can cause 
conversations about the causes of build failures that are best done in 
"dev". Currently they're sometimes done in "dev", sometimes in "cvs" or 
"build" and often the conversation switches at some arbitrary point when 
somebody realises they're on an inappropriate channel.

There's an argument that both CVS and build notifications (as well as 
anything else that might be related) should be in the same group as 
technical discussion. In fact we used to operate this way some years back 
but there sufficient feeling that they should be split that we did so. 
More recently we've also had the need to split some technical discussion 
into different groups.


Anyway, the first new attribute is "Reply-To", which specifies the name of 
a group that replies should be sent to by default (if different to the 
current group). The intended use of this is producers in the second case 
above. Both our CVS and build producers set a "Reply-To" attribute with a 
value of "dev" and, if ticker clients honoured it, follow-up discussion 
would always go to "dev" unless explicitly overridden by the user. I don't 
see a particular need for the GUI of Tickertape clients to be complicated 
by an option to set it on outgoing notifications, though.

The other attribute is "Reply-From", which specifies the name of the group 
of the message that this message is in reply to (if different to the 
current group). For example, anybody replying to a CVS notification would 
set a "Reply-From" attribute with a value of "cvs". This allows other 
consumers to see where it was that something came from, and possibly 
assist them in getting context if they needed to. I would suggest that 
Tickertape clients, as well as emitting the attribute where appropriate, 
display the message with "(from cvs)" prepended, or something along those 
lines. This includes scrollers and threaded history displays within both 
clients and loggers where the message parent is not shown immediately 
above the message.

Below is an example of both attributes in use:

--- A commit notification on "cvs", with replies directed to "dev":
Group: "cvs"
From: "alice at example.com"
Message: "In yatc: Modified scroller.s: Initialise foo before bar so that 
baz doesn't break. Fixes bug #123."
Reply-To: "dev"
Message-Id: "a"
--- A follow-up comment directed to "dev" by the Reply-To attribute:
Group: "dev"
From: "alice at example.com"
In-Reply-To: "a"
Reply-From: "cvs"
Message: "I think that's the last of the serious bugs fixed for this
week. We can move on to those new features next week."
Message-Id: "b"
--- A reply directed to "Chat" by hand:
Group: "Chat"
From: "bob at example.com"
In-Reply-To: "b"
Reply-From: "dev"
Message: "Yay! I reckon that makes it beer o'clock."
Message-Id: "c"
---

Possibly both attributes should have "-Group" on the end of them to make 
them a bit less ambiguous and to reduce the chance of collision with 
something different in the future. "Reply-From" could possibly also do 
with a better name.

Any thoughts? Anybody interested in implementing this?

Ian