Community
Participate
Working Groups
I would like to get rid of the term "plugin" in the UI (and ultimately, in the code, too). Since the extensibility mechanism in Orion is quite different, I believe we should not be using the term "plug-in". My suggestion would be to use "extension" instead. Any other suggestions?
+1 for rename. What we are really talking about is a "thing that contributes services and extensions". I.e., the unit of reuse and extensibility is individual services and extensions. Contrast with eclipse desktop where bundle/plugin is the basic unit of reuse/composition. A plugin in Orion today represents a host or domain that is contributing a particular set of services and extensions. I was thinking along the lines of "Site", "Contributor", "Provider", "ExtensionSite", "ServiceProvider", "ExtensionProvider", "ContributionHost", etc. The key difference is that it is "a thing making contributions" rather than a "a thing that is being contributed". Actually come to think of it, our JS API uses the term "provider" already so maybe that is a good fit.
Currently these are "things" that contribute services. Which is why I suggested "extension" as the name for the "things". Makes sense?
(In reply to comment #2) > Currently these are "things" that contribute services. Which is why I suggested > "extension" as the name for the "things". Makes sense? +1. Providers can define extensions which cause new behavior/function to appear in Orion. These extensions are implemented in a service registry. One thing I'm not clear on. Today we have some services in the registry (20 things, etc.) that are "core" to Orion and are not documented anywhere as an extension. Do we call these things services instead of extensions? Do we not mention them at all? Or do you think the term "extension" applies to any behavior in what we now call the service registry?
A couple of worries about using "extension": - If we ever introduce an extension registry in Orion, the name would obviously be confusing. We wouldn't be able to use the term "extension" the way it is used in Equinox today. I don't know if Simon is still considering an Orion extension registry - There is still a terminology overloading for those familiar with Eclipse. In Eclipse and "extension" is a singular contribution rather than an entity that makes many contributions. Extension is a fine term, but if the purpose of moving away from "plugin" is to avoid confusion with Eclipse terms, I don't think it accomplishes that.
(In reply to comment #4) > - If we ever introduce an extension registry in Orion, the name would > obviously be confusing. We wouldn't be able to use the term "extension" the way > it is used in Equinox today. I don't know if Simon is still considering an > Orion extension registry My assumption has been that services are what you can contribute - where each service, in effect, is a JavaScript object that can have properties and functions. I don't see why we would also need a concept similar to Eclipse extensions. Simon?
(In reply to comment #5) > My assumption has been that services are what you can contribute - where each > service, in effect, is a JavaScript object that can have properties and > functions. I don't see why we would also need a concept similar to Eclipse > extensions. Simon? Simon and I just chatted about this. Effectively what we have today is a hybrid between OSGi services and Eclipse extensions. Because of its declarative aspect and lazy loading ability, we effectively already have something like the classic Eclipse extension registry so I agree we wouldn't need to introduce another concept.
Apparently I'm slow on the trigger... http://en.wikipedia.org/wiki/Plug-in_(computing)#Compared_to_extensions -- To be honest after waffling I think I'm ok with either "orion plugin" or "orion extension" as the top-level concept so I'm sort of -.1 here but only because of churn. I also like the term "provider" and think it makes sense on the implementation- side as the main term and is John points out that's already reflected in the API. (e.g. write a PluginProvider/ExtensionProvider to contribute a plugin/extension). As far as something like a desktop style extensionregistry goes I think we will not need it and frankly I would like to avoid the service/extension confusion again. What we have is a hybrid along the lines of OSGi declarative services and I think we can handle the same sorts of lazy-loading and metadata that were valuable.
"add-on"?
I think I misunderstood before. By suggesting the word "extension," I thought you were looking for a word for a particular contribution (service/extension) but you are looking for a word for "the unit of contribution of one or more services/extensions." In other words, what do we call that html page + code that someone adds. Yes? If so, then I think extension is a misleading word due to past usage (it confused me as to what you were trying to name). (In reply to comment #8) > "add-on"? Better than "extension." The downside is possible confusion by FF users who think that we are referring to true FF add-ons (Tools->Add-ons). But we are going to have that possible confusion if we use any existing/known term (plug-in, extension, service, add-on). And it doesn't seem useful to invent a new term to avoid confusion with the existing ones. (tools for Orion's toolbelt?) So I like "add-on" the best
As we start to write more documentation in the coming weeks, we need to close on this. In the end the term we use isn't important to me, but it is important that we pick words that we use consistently throughout or documentation, discussions, etc. Knowing that the "contributed things" will always be called "services" simplifies the problem for me. Whether the thing that contributes services is called a plugin, extension, or add-on, doesn't much matter to me. The worry about confusing existing Eclipse developers is probably not so important in the end - our target users will be more familiar with browser add-ons/extensions than Eclipse plug-ins. Maybe hold a vote in the planning call tomorrow?
We're using plugins for now.
