4 ms·

I realize it's just an early draft, but it's interesting (alarming?) that the proposed plugin API has no facilities for plugin discovery or separate namespaces.

I realize it's just an early draft, but it's interesting (alarming?) that the proposed plugin API has no facilities for plugin discovery or separate namespaces. Nor any apparent ability for the plugin consumer to introspect into plugins. I suppose the namespace issue can be mitigated by a strict naming convention (something like "[application_name].[plugin_name]"), but the others are kind of a bummer. I don't have a whole lot of positive things to say about the Python setuptools API (perhaps better called "lack-of-API internal interface"), but at least it's possible to dynamically load python plugins from arbitrary locations in the filesystem and programmatically discover their contents.

nteon 12y ago
I'm not sure I see the benefit of plugin discovery or separate namespaces. Loading a plugin gives you a Plugin struct, which is a namespace to lookup symbols (functions + globals) from that plugin. Most plugins would I think by necessity be application specific, so I'm not sure how much gain there in in some sort of plugin discovery. But the process of loading a plugin would also allow the plugin to call into your code to register handlers & data structures in the main application through init() functions. From a security perspective, executing arbitrary code in your address space in order to discover the contents of a plugin sounds ill-advised. To me, it looks like they're building the low level building blocks that allow a number of different higher level APIs to be built, which is pretty neat.
ianlancetaylor 12y ago
The plugin API uses file names, so discovery would be at a higher level. Go packages impose their own namespace, so there shouldn't be any namespace issues. Introspection is useful, but would be a matter of examining the files using existing packages like debug/elf; it would not be part of the plugin API. Basically the plugin API is isomorphic to dlopen/dlclose. Everything else is built on top of that.
- bkeroack 12y ago
  OK, if true that makes sense. I was interpreting the Name parameter to Open() as being something like a global plugin name rather than a filesystem location. That combined with the Plugin struct (which hopefully would have something like an iterable Map of exported symbols) resolves the issues I was concerned about. Nice.

nteon 12y ago

I'm not sure I see the benefit of plugin discovery or separate namespaces. Loading a plugin gives you a Plugin struct, which is a namespace to lookup symbols (functions + globals) from that plugin. Most plugins would I think by necessity be application specific, so I'm not sure how much gain there in in some sort of plugin discovery. But the process of loading a plugin would also allow the plugin to call into your code to register handlers & data structures in the main application through init() functions. From a security perspective, executing arbitrary code in your address space in order to discover the contents of a plugin sounds ill-advised. To me, it looks like they're building the low level building blocks that allow a number of different higher level APIs to be built, which is pretty neat.

ianlancetaylor 12y ago

The plugin API uses file names, so discovery would be at a higher level. Go packages impose their own namespace, so there shouldn't be any namespace issues. Introspection is useful, but would be a matter of examining the files using existing packages like debug/elf; it would not be part of the plugin API. Basically the plugin API is isomorphic to dlopen/dlclose. Everything else is built on top of that.

bkeroack 12y ago
OK, if true that makes sense. I was interpreting the Name parameter to Open() as being something like a global plugin name rather than a filesystem location. That combined with the Plugin struct (which hopefully would have something like an iterable Map of exported symbols) resolves the issues I was concerned about. Nice.