jmuehlner commented on PR #668: URL: https://github.com/apache/guacamole-client/pull/668#issuecomment-1089138224
Hey Nick! So I've had a more thorough look through this and the [backend changes](https://github.com/apache/guacamole-server/pull/358/files#diff-cec0f31d33a52d11818f03d91a6076415f717f58d61ab09b73009df961d8238fR685-R686) and I have a couple of thoughts. First off, I really like this idea. Having join notifications will be an awesome feature, something that I would enjoy quite a bit. The new `msg` instruction would also be really handy for implementing some features that I was thinking about as well, but I think a few tweaks would make it more extensible. One thing is that we don't want to be generating messages for display directly on the backend - this bypasses the translation system on the frontend, and is something we've avoided in the past. We can still send a human-readable message for debugging purproses (like we do with ack, etc), but it shouldn't be used for display to the user. If the `msg` instruction contained "msg code" or something like that, the frontend can render something based on the code, as well as any arbitrary arguments that might accomopany any given code. These arguments could contain, for example, a user identifier that could be used to generate (using the translation system) the same message that you're currently generating on the backend. Or, using a different event code, the frontend might render something completely different (a session recording notification, or a notification that a user is already in a connection, etc). The frontend could just ignore any event code it doesn't understand. On the subject of username, I think it would be better to send a machine-readable user identifier (like the user ID perhaps) than the actual text username. The frontend would know what kind of identifier it sent, and would therefore know how to render any notification based on it. This could maybe be part of a generic connection context provided to the backend, which may include other things that just the user ID. On a side note, having a user ID on the backend would be really cool since it would allow the the user log functions to actually differentiate based on user in the log. So to summarize, this is what I was thinking: #### The frontend can provide some context when a connection is established, including some user identifier and possibly other things. #### The `msg` message type could contain: * A "msg code" (not sure about the name) that contains a machine-readable message type that the frontend will know how to render based on. * An arbitrary list of arguments that is specific to the "msg code" - in the case of the user join / leave messages this would be the user identifier previously supplied in the handshake. * A human readable message for debugging purposes. Does that seem reasonable? @mike-jumper any thoughts? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
