mike-jumper commented on a change in pull request #547:
URL: https://github.com/apache/guacamole-client/pull/547#discussion_r453140909
##########
File path: guacamole/src/main/webapp/app/client/controllers/clientController.js
##########
@@ -44,6 +44,16 @@ angular.module('client').controller('clientController',
['$scope', '$routeParams
var requestService = $injector.get('requestService');
var tunnelService = $injector.get('tunnelService');
var userPageService = $injector.get('userPageService');
+
+ /**
+ * Counter and limiter for maximum auto-reconnect attempts that we
should
+ * automatically try to establish a connection when
CLIENT_AUTO_RECONNECT or
+ * TUNNEL_AUTO_RECONNECT error types occur.
+ *
+ * @type Number
+ */
+ var AUTO_RECONNECT_TRY = 0;
+ var AUTO_RECONNECT_MAXTRY = 4;
Review comment:
> Why can't we just use `guacamole_connection_parameter` which already
holds all kind of profile parameters under column named `parameter_name`???
Because those aren't connection parameters. Connection parameters are a
specific type of name/value pairs and are defined by the protocol plugins used
by guacd. Connection parameter storage should not be used for anything that
isn't a connection parameter.
There _is_ a built-in facility for arbitrary name/value pair storage for
connections (connection attributes), and this would be the appropriate vehicle
for these changes. New connection attributes do not generally require schema
changes, at least in the case of non-standard attributes.
Thus: connection parameters would be a non-starter, but connection
attributes would be (generally) fine.
The awkwardness in this particular change comes from:
* If the web application will have built-in handling for these attributes,
they should be standard attributes, perhaps part of the API.
* Standard attributes (those which are standardized by the extension API)
really should be stored within properly-typed columns. This is already done for
the existing standard connection attributes.
* We desire to not modify the database schema, as doing so breaks backward
compatibility ... but _not_ modifying the schema in this case would mean that
we deviate from established convention that is grounded in good technical
reasoning (attributes that are standard really should be able to be queried
directly).
So ... yes, you're not wrong that it could be done as you describe, but it
really should not be.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
