[Council] Message threads

[Ian Paterson]

Kevin Smith wrote:
> Uniqueness:
> I support the long-term uniqueness, as I want threads to be 
> indefinitely lifetimed too. It creates a slightly strange situation 
> though - "For messages of type 'groupchat', the value of the <thread/> 
> element MUST be unique in the context of the multi-user chat room, as 
> long as the room remains in existence" - how does a client that's just 
> joined the chat know that a thread hasn't previously been used? This 
> is also true between single entities, as they may be using different 
> clients. For MUC, it is (later) said that there could be a method to 
> ask for a unique thread, but that it's out of scope - we should 
> probably give a reference to some place that it's in scope if we can.

Yuck. If your thread ID contains enough bits of randomness (e.g. 20 
base64 characters = 120 bits) then this shouldn't be a problem anytime 
before the human race becomes extinct. ;-) IMHO bugs in the relatively 
complex stateful code that is required to "guarantee" unique IDs are a 
much more likely source of collisions than very large random numbers. 
(I'm a fan of employing randomness instead of stateful counters to 
"guarantee" uniqueness if it makes code significantly more simple.)

> Handling:
> Again, here I'd quite like to see it changed for equal emphasis on 
> non-chat messages

+1

> Inclusion:
> I'd like normal to be changed to RECOMMENDED if people don't 
> vehemently object.

Hmm, Message types "chat" and "groupchat" are the most important targets 
of this spec. But I'm not entirely sure I understand what you mean. 
Assuming I do, I'm not sure why you might want that. Could you please 
elaborate?

- Ian