Talk:Settings Proposal - Revision history

IJs at 00:56, 14 September 2007

2007-09-14T00:56:28Z

← Older revision		Revision as of 00:56, 14 September 2007
Line 22:		Line 22:

	--[[User:Talidan2\|Talidan2]] 15:11, 7 September 2007 (CDT)		--[[User:Talidan2\|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.

			--[[User:IJs\|IJs]] 19:56, 13 September 2007 (CDT)

Talidan: /* Suggestions */

2007-09-07T20:17:46Z

Suggestions

← Older revision		Revision as of 20:17, 7 September 2007
Line 19:		Line 19:
	--[[User:IJs\|IJs]] 07:08, 7 September 2007 (CDT)		--[[User:IJs\|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.		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.

	--[[User:Talidan2\|Talidan2]] 15:11, 7 September 2007 (CDT)		--[[User:Talidan2\|Talidan2]] 15:11, 7 September 2007 (CDT)

Talidan at 20:11, 7 September 2007

2007-09-07T20:11:20Z

← Older revision		Revision as of 20:11, 7 September 2007
Line 18:		Line 18:

	--[[User:IJs\|IJs]] 07:08, 7 September 2007 (CDT)		--[[User:IJs\|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.

			--[[User:Talidan2\|Talidan2]] 15:11, 7 September 2007 (CDT)

IJs at 12:10, 7 September 2007

2007-09-07T12:10:20Z

← Older revision		Revision as of 12:10, 7 September 2007
Line 15:		Line 15:
	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).		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. The latter saves us performance and memory usage.		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.

	--[[User:IJs\|IJs]] 07:08, 7 September 2007 (CDT)		--[[User:IJs\|IJs]] 07:08, 7 September 2007 (CDT)

IJs at 12:09, 7 September 2007

2007-09-07T12:09:56Z

← Older revision		Revision as of 12:09, 7 September 2007
Line 15:		Line 15:
	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).		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.		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. The latter saves us performance and memory usage.

	--[[User:IJs\|IJs]] 07:08, 7 September 2007 (CDT)		--[[User:IJs\|IJs]] 07:08, 7 September 2007 (CDT)

IJs at 12:08, 7 September 2007

2007-09-07T12:08:53Z

← Older revision		Revision as of 12:08, 7 September 2007
Line 16:		Line 16:

	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.		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.

			--[[User:IJs\|IJs]] 07:08, 7 September 2007 (CDT)

IJs at 12:08, 7 September 2007

2007-09-07T12:08:37Z

← Older revision		Revision as of 12:08, 7 September 2007
Line 10:		Line 10:

	--[[User:Jbeta\|jbeta]] 06:41, 7 September 2007 (CDT)		--[[User:Jbeta\|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.

Jbeta at 11:50, 7 September 2007

2007-09-07T11:50:09Z

← Older revision		Revision as of 11:50, 7 September 2007
Line 3:		Line 3:
	I can see how the '.' notation simplifies things, but what are the benefits of the #, * symbols over a simple "access" xml attribute?		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. If this isn't possible, I think the set/get accessors should be renamed to something more explicit, like getOption/setOption.		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.

	--[[User:Jbeta\|jbeta]] 06:41, 7 September 2007 (CDT)		--[[User:Jbeta\|jbeta]] 06:41, 7 September 2007 (CDT)

Jbeta at 11:43, 7 September 2007

2007-09-07T11:43:43Z

← Older revision		Revision as of 11:43, 7 September 2007
Line 3:		Line 3:
	I can see how the '.' notation simplifies things, but what are the benefits of the #, * symbols over a simple "access" xml attribute?		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 ~~global variables to~~ 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. If this isn't possible, I think the set/get accessors should be renamed to something more explicit, like getOption/setOption.		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. If this isn't possible, I think the set/get accessors should be renamed to something more explicit, like getOption/setOption.

	--[[User:Jbeta\|jbeta]] 06:41, 7 September 2007 (CDT)		--[[User:Jbeta\|jbeta]] 06:41, 7 September 2007 (CDT)

Jbeta: Suggestions

2007-09-07T11:41:48Z

Suggestions

New page

== 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 global variables to 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. If this isn't possible, I think the set/get accessors should be renamed to something more explicit, like getOption/setOption.

--[[User:Jbeta|jbeta]] 06:41, 7 September 2007 (CDT)