Support namespaces for plugins

#40

Currently, plugin signatures go into a global namespace. Hence, if there are two different plugins that include the following in their respective MWLibrary.xml:

<match_signature>stimulus[@type="foo"]</match_signature>

then MWorks has no way to distinguish them. Hence, if two different groups want to implement a stimulus called "foo", then they either have to coordinate their naming (e.g. agree to call one implementation "fooA" and the other "fooB") or avoid having both plugins installed on the same system.

To avoid such conflicts, we could allow plugins to specify a namespace to which they belong, probably somewhere in MWLibrary.xml. I'm not sure what the best syntax would be. Maybe:

<MWElement name="Foo stimulus" namespace="edu.mit.dicarlolab">
  <match_signature>stimulus[@type="foo"]</match_signature>

or, alternatively:

<MWElement name="Foo stimulus">
  <namespace>edu.mit.dicarlolab</namespace>
  <match_signature>stimulus[@type="foo"]</match_signature>

This would allow different groups of MWorks users to name their plugins' elements as they like, so long as each signature is unique within the specified namespace.

Reported by Christopher Stawarz · April 30th, 2010 @ 01:27 PM

Activity

David Cox
- Assigned user set to David Cox
We'll need to carefully decide what the correct behavior is for handling this. And even with a namespace mechanism in place, we should endeavor to avoid name conflicts if at all possible, just for the sake of avoiding (ordinary, user) confusion -- it's not like there are hundreds (or even dozens) of people writing plugins, so this will hopefully not be a terribly common occurrence. Even if MWorks can flawlessly resolve the situation, it is still confusing if two groups produce "DriftingGrating" stimulus components that behave differently.

Currently, if two plugins register with the same name, the Server emits an error and refuses to load an experiment until the duplication is resolved. This places the onus of constructing a coherent plugin suite on whoever builds the distribution/installer.

I think we still want (loud, fatal) errors if a user attempts to reference a component that is ambiguous, but this ambiguity could possibly be resolved in the new regime by one or more of the following mechanisms:
1. "inline" namespace syntax, e.g.: stimulus type="edu.mit.dicarlolab::foo
2. an additional xml property: stimulus type="foo" namespace="edu.mit.dicarlolab"
3. a global directive: using-plugin-namespace id="edu.mit.dicarlolab"
I think that any/all of these options would be reasonably straightforward to implement. Currently, the core does not parse the MWLibrary.xml at all when loading plugins (it gets passed the component/type info it needs when the plugin object registers itself), but this would easy enough to include.

An even more pressing issue, I think, is versioning / dependencies. While I think we're probably doing something very wrong if three different groups have three different DriftingGratingStimulus objects that somehow all get installed on the same machine, it seems much more likely that there will someday two different (potentially incompatible) versions of the same plugin. The 2nd strategy (an additional xml property), above, could also easily specify a version/dependency property. The original plugin registration system had dependency tracking, but it was not replaced when the whole XML parsing infrastructure was refactored. This seems like a much higher priority to me.
May 4th, 2010 @ 09:31 AM
Christopher Stawarz
- State changed from new to open
[bulk edit]

April 8th, 2011 @ 10:49 AM
Christopher Stawarz
- State changed from open to hold
October 17th, 2012 @ 10:53 AM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.