Talk:Settings Proposal
Suggestions
I can see how the '.' notation simplifies things, but what are the benefits of the #, * symbols over a simple "access" xml attribute?
Also, how about just exporting settings as key-value pairs under a global "settings" table in the resources' VMs? No set/get is required that way provided that you could update the vars' values for all VMs simultaneously after an assignment.
There's a major advantage to this method: since scripters will be using the settings table directly, any change will instantly apply. Using get/set, scripters would be likely to store the settings on load and a resource restart would be necessary.
If this isn't possible, I think the set/get accessors should be renamed to something more explicit, like getOption/setOption.
--jbeta 06:41, 7 September 2007 (CDT)
The point behind the (protected, private and public) access operators is that variables can be prevented from being read-out (or changed) by any resource. For example, if a certain resource (set up by the admin of a server) uses a password setting or other confidential data, one could prevent it from being read out by an administration panel (that could be accessed by lower-level admins on the server).
The disadvantage of using a "global" table in lua code is that people will automatically assume that any table is declared within the lua code, and not declared by MTA. To differentiate between that, you could either use a very distinct name, or a separate query method (get, set).
Also, from a programmer's point of view, implementing a "global" table requires a push-system, whereas get/set query functions will form an on-demand pull-system. This means that, in the first case, a change to every registry setting from every resource would require us to update all copies of the "global" tables in all virtual machines to properly synchronize the registry. If we used the query functions, we would only have one central place where we stored and retrieved our values from.
--IJs 07:08, 7 September 2007 (CDT)