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 any registry setting from any 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. The latter saves us performance and memory usage.

--IJs 07:08, 7 September 2007 (CDT)

I think any registry values in meta.xml should be protected rather than private by default. Imo, most of the time such settings values are useful to be read by other resources, and dont really store private data. Also, i can see a registry being very useful clientside too. It would allow users to save their favourites skins or anything of that sort. It could work in a very similar manner as serverside.

--Talidan2 15:11, 7 September 2007 (CDT)

I disagree, mainly because of the ability of get to list ALL settings in the server (that the resource has access to). If we set it to protected by default, people may forget to put prefixes in front of their settings and compromise any secrets that could be revealed by admin resources that use this functionality. Classes in C++ are also private by default, there's a good reason for that.

Anyways, someone needs to do the documentation asap! I've updated the specs.

--IJs 19:56, 13 September 2007 (CDT)