Community
Participate
Working Groups
Ken and I were talking about ways to make library integration(s) better, and one idea we came up with was an installed library - basically all the support for a given library in one package that could be used by the JS tools (or Orion in general). For example - MongoDB - we currently have an index file for it, but there also could be templates, API doc, etc that could be contributed. So rather than N different contributions (one for index, N for templates, etc) we could have a new extension point that would allow a 'library' to be defined that could in turn provide all the stuff related to that particular library. Thoughts? Ideas?
What problem are we solving here? Is there some some sort of perf problem with a plugin contributing multiple services related to a library or ...?
(In reply to Simon Kaegi from comment #1) > What problem are we solving here? Is there some some sort of perf problem > with a plugin contributing multiple services related to a library or ...? There is no performance issues, there are few problems that we could be solving here: 1. make it easier for contributors to extend the JS tools. For example, rather than a contributor having to use N extension points and merge stuff together (imagine a 3rd party providing JS templates; how would that get properly merged / sorted in with the default JS templates) they could contribute a library object to our one extension point and we handle all the merging, etc. 2. If in the future we wanted to have UI that would allow users to configure/enable/disable a library it would be far easier to just filter out that contribution (the whole lib) rather than filter contributions from a pile of extensionpoints 3. Think of one of these libraries like the installed JRE from Eclipse - everything you need is contributed in one place, easy to configure - for example a library object might look like: { getIndex: function(){}, getTemplateProposals: function(){}, getKeywordProposals: function(){}, getCompletionProposals(): function(){}, getAPIDocumentation: function() {}, getPreferenceId: String, isAutoLoading(): Boolean }
I could see the script mapping also playing a role here, each library could provide a mapping to find its files (in their default location)
With the support in the tools being provided as Tern plugins, we no longer need the idea of an 'installed library'. See bug 432940 for Tern support. Closing wontfix.
