telrikk
commented
12 years ago I don't think option two is abusing the concept of a message. We seem to have three subgroups.
- Messages - these are messages that appear on the messagelist. They can be from the "server" to a player or players, such as a "telrik has joined the channel" message, or from a player to a channel, like "
hihi", or from a player to a player (eventually.) The defining part about a message is that it goes into the messagebox. - Errors - These can be written anywhere. The fact that they show up on the messagelist is coincidental. The important part is that they're not universally displayed, and show a failure of some action that was performed.
- System Changes - Stuff like the join payload. These change how things work in the background (stuff like a new player joining), and possibly reflect some gui changes (adding people to the user list on the right.) This stuff isn't directly reflected in the messagelist, since it's in the background.
I do like option one though. I think that as you said, since we're building a platform, that it makes sense to have the client decide how to render information specific to a project. In torMP, I can imagine the join message being very different to help reflect the MP atmosphere. Also, if we put this and similar messages on the client side, we allow people to localize (languagewise) potentially for us. Basically, what you said.
I'd say option one is definitely best, but it's not important enough to be a first priority atm.
slifty
I think I seeded this decision in the first iteration of IRC, but I think we should discuss it.
Right now the handleJoin message sends the following payloads:
1) Join payload is sent to everyone (the user shows up on the list on the right hand side) 2) Messages to the connecting user with things like MOTD 3) A message to everyone announcing the join (the "user has joined" message appears in console) 4) Join messages to the connecting user to let him know that users have joined
The question on the table is whether or not we should keep a separation between the "Join" and the "Message" payload.
OPTION 1: Join "message" (step 3 above) is taken away This would mean the clients only get a single join payload (#1) when a new person joins. The joinOut method in irc.js would then need to create and render the message. One benefit of this is localization (if the join message content is constructed on the client in response to a join it can be in their language), another is that it gives client more control over how to alert the end user of a join.
If we do this we have to rethink step 4, since we don't want to have people get a "USER HAS JOINED" message for every person already in the room (if you are the 4th to connect for instance). It's possible the current user list could be sent out separately in either a new payload, or as part of an existing payload.
OPTION 2: No change to the way it works now. This might be abusing the concept of a message, however.
Note that what we do here will affect what we do for other types of messages. Such as leave. Option 1 fits in more closely with what we're doing with errors which is why I'm bringing it up.