The Alphaville Herald

Players Dodge Horrific Namespace Collisions!!!

by Alphaville Herald on 22/10/09 at 10:57 pm

Metaplace developers hope to avoid each other's triggers

by Suzie Skybeam

Wednesday night, a group of developers got together in a Libertarian coffee shop to discuss what to do about the Metaplace's lack of namespaces.

In Metaplace, you can attach scripts from different modules to the same object. For example, a chat system and a combat system written by different people might both be attached to the same "player" object. The problem is that "properties" (used to store the current state of an object) and "triggers" (used for communication between objects) aren't local to a module, so if two modules happen to use the same name for a property or trigger, they will interfere with each other, and probably won't work properly.

DougQB explains: "a Builder who doesn't know how to code starts putting  a bunch of modules together and then starts changing/breaking things. Then wants someone to fix it."

Many people felt that the best solution would be a change to the Metaplace version of the Lua programming language, but weren't optimistic that would happen any time soon.

chooseareality: "a private declaration would be great.. sigh"
KStarfire: "Exposed Triggers is the best solution altho even that  i dont think it would completely fix it"
LunarRaid: "It's a pity triggers aren't prefixed with the script name by default."

In the short term, the problem can be worked around by making the names of properties and triggers start with a prefix that ensures they don't accidentally clash with someone else's. AthSkytower suggested having a registry of the prefixes that people are using, but another proposal was to just use the module id as a prefix: modules are already assigned unique ids.

That takes care of the properties and triggers that are only intended to be used within a module, but there are also some that are intended for use as interfaces between modules. AthSkytower suggested creating a Wiki page where these "public" triggers are registered and their method of use is documented.

There was some discussion of whether it was good coding style to use properties for communication between modules. The consensus seemed to be to allow people to register these too, even if not everybody approves of the practise.

AthSkytower: "I think maybe we should include them, at least at first, just because they are used and I suspect the notion will get less popular if we try and enforce coding style. "
jme: "Probably good to keep religion out of this."

Finally, there were also security issues. What if someone deliberately uses the name of another module's trigger, in order to gain some advantage? The default avatars module, for example, is flagged as "closed source" so that other modules can't get at its internal state … at least, in theory they can't.

If prefixes are registered, or determined by the module id, then an attacker can figure out what the prefix is, but the rest of the name of the trigger can still be a secret.

AthSkytower: "Knowing that my functions all start with ath_ doesn't help anyone know to call ath_monkeyfishhats if the script's closed."

Unfortunately – as Obo pointed out after the meeting had finished – the reflection API lets you find out the names of a module's triggers, even if it's closed source, so this doesn't work as a security mechanism.

By the end of the meeting, we'd heard some good suggestions on how to stop modules breaking accidentally – but the security problem was still unsolved.

A full transcript of the discussion has been posted to the "scripting" forum on the Metaplace web site here.