Mason and dynamic loading: do we need a new kind of a Mason project?

[e-kayrakli]

In a world where we can dynamically load Chapel libraries into Chapel applications, what can Mason do to help navigate the landscape?

Say, I have an application. And some dynamic plugins that I may need at execution time dynamically. In that scenario, plugins can't exist on their own. Does Mason have a way to express that today?

• Are plugins part of a Mason application? I hardly think that's a good idea, as that would make third-party plugins nearly impossible unless I am missing something.
• We can make plugins libraries, but I feel like a plugin is more specific than a library, or maybe a specific kind of a library.
• Do we need a new kind of mason project on top of application and library, like plugin. A mason project like that could specify the mason application it is written for. Internal implementation-wise, I don't think it will be much different than library, though. It will be only to prevent a plugin to be pulled in for an application that it is not designed for.

[mstrout]

Could you more clearly define what characterizes a plugin?

• It sounds like it isn't a shared library? Maybe you could say how it differs from a shared library?
• when you say it "can't exist on their own", what does that mean? It can't execute? but neither can a shared library typically. It has dependencies on a library or application?

[e-kayrakli]

I don't know if these are textbook definitions, or if there is any. To me:

• static library: a library that can be statically linked to any application in a meaningful way.
• dynamic library (or "shared" as you used that term): same, but with dynamic linkage, e.g. at application launch time
• plugin: designed more specifically for an application and loaded dynamically, e.g. at any time during execution as needed.

I don't know if "designed more specifically" is well-defined. When I think about a plugin, I expect to see an application which specifies an interface that it expects from a plugin, and the plugin is designed specifically for that interface. For a dynamic library, I think the interface design is part of the library itself, and an application that wants to use it, must adhere to that. So, "can't exist on their own" is more of a plug-in thing for me. But maybe it is a more abstract distinction than necessary.

Again, I am happy to adjust my terminology if it is misleading or wrong.