Closed DamonOehlman closed 10 years ago
How about adding the sender tag as an additional JSON struct so you can add additional admin messages if necessary, e.g.
/chat|{"message":"Hello","src":"95cc43aa-9f39-4e53-88b7-3bee18b88c2a"}|{"_sender":"~95cc43aa-9f39-4e53-88b7-3bee18b88c2a"}
Could for example add a timestamp: /chat|{"message":"Hello","src":"95cc43aa-9f39-4e53-88b7-3bee18b88c2a"}|{"_sender":"~95cc43aa-9f39-4e53-88b7-3bee18b88c2a", "_sentAt":"20140103T11:15"}
Yeah, that's probably a good point although I'm keen to keep message sizes as small as possible. Also to clarify the ~
character is used directly after the pipe so you can extract the metadata prior to sending the info on for further processing. So the timestamp version of the message would look like this:
/chat|{"message":"Hello","src":"95cc43aa-9f39-4e53-88b7-3bee18b88c2a"}|~{"sender":"95cc43aa-9f39-4e53-88b7-3bee18b88c2a", "sentAt":"20140103T11:15"}
Maybe I should implement this behaviour directly in the signaller rather than the switchboard, so adding custom metadata is something that can be done at an application level simply? In reality though adding your own custom metadata has always been pretty easy. The only reason I thought the signaller id should be included by default in all messages is that a received message doesn't make much sense without it.
Yep, apparently I registered a bug against the signaller for this a while ago: rtc-io/rtc-signaller#2
I think I'm going to trust my past self on this one and implement the behaviour there (next week).
sounds good :-)
Implemented in the rtc-signaller
as discussed. Closing.
I'm currently improving the signaller documentation at the moment (specifically the send function). While it makes sense for a signaller not to send any identification as part of the message (for the sake of keeping message size small) it would probably be helpful for the switchboard to mark messages as they are distributed with the source of the message.
The question here is how to do this in a way that does not break older versions of the signaller that will connect to a signalling server. As the signaller looks for message parts delimited by the pipe
|
character it should be simple enough to add an additional message part to the end of the message with the source id.Specifically, I'm thinking using an additional character to enable the signaller to pick this component of the message out prior to other processing.
For instance, a custom
/chat
message might have been sent before using the signaller like:Which would translate into the following:
With the sender tag attached the message might look like this instead:
In each case, the signaller would be able to process these custom chat messages using the same syntax of:
While the new switchboard coded message would have an additional argument provided to the event handler, this would not impact event handling.