[Bug 39415] New: Make configuration settings accessible through the website
https://bugs.winehq.org/show_bug.cgi?id=39415 Bug ID: 39415 Summary: Make configuration settings accessible through the website Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Currently the way to change a configuration setting is to send a patch to wine-patches and have Alexandre apply it. This is the case for instance for all the VM host configuration settings ($MaxRevertingVMs, $MaxRevertsWhileRunningVMs, etc.), but also $JobPurgeDays, $RegistrationQ, etc. This is not very practical and prevents experimentation or quickly adjusting the settings when a problem arises. Instead these should be stored in a Parameters table and be accessible through an administrator-only section of the website. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39415 Damian <axl-damian(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |axl-damian(a)o2.pl -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39415 --- Comment #1 from François Gouget <fgouget(a)codeweavers.com> --- One way to handle this would be to add a table like this: PK Class # User, VMHost, VM, etc. PK Object # User name / Hostname / VM name, etc. PK Property # Name of a property of the above object Value # Value for that property The point of the Class column is to avoid collisions between the properties of the w1064 VM and those of a malicious w1064 user: the class would ensure they resolve to ('VM', 'w1064', ...) and ('User', 'w1064', ...) respectively. Then the API to access those should provide automatic fallbacks so if a the SleepAfterRevert property is not specified at the VM-level, either the VM-host one or the global one is used: my $Props = GetProperties(['VM', 'w1064'], ['VMHost', 'vm2'], ['Global', 'VMHosts']); print $Props->{SleepAfterRevert}, "\n"; Should the need arise for array properties (maybe to store user preferences like VMs to run the tests on) the convention could be to suffix the property name with ":array" and then ":N" for each entry (colons would otherwise be forbidden in property names). GetProperties() would likely provide access to a singleton object that loads all of a given object's properties at once and then caches them for a few seconds so that iterating over VMs (for instance) does not cause the VMHost properties to be reloaded each time (this assumes the Perl ORM does not provide such functionality). Of course a SetProperty() method would update the cache appropriately, but of course that does not help other processes, hence the short-duration case. Interestingly this new table would have no link to the other TestBot tables, making this a good testing ground for Perl ORM tests. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39415 --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- The GUI may want to hide the per-User settings: * Once user settings are implemented they are likely to constitute the bulk of the Settings table owing to both the number of users and the number of settings per user, particularly depending on how the user's VM preferences are stored. * Also the administrator should not need to see a user's preferences. Besides that, accessing this table's content could work through the regular 'CollectionBlock' GUI (though a GUI allowing editing the table directly would be more user friendly). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla