Community
Participate
Working Groups
Indexing is currently performed on first search attempt. If the product is large, this can take a long time, resulting in a frustrating initial search experience. Ideally, local help should be indexed on first startup in the low-priority background thread. However, we don't want to encourage that in the platform itself. Products can elect to register a startup plug-in and tell the help system to initialize from there. We propose to add the new API 'init()' to both IHelpSystem and AbstractHelpSystem types. The default implementation should be no-op. The role of the method would be to allow help systems to place whatever initialization code is needed to run the help system. Eclipse help system will use this method to run the indexer if needed. If the index is already created, the method should return immediately. Otherwise, it should schedule a background job to index the documents ahead of the search request.
Kim, I don't know if you noticed, but this API needs to be added to IHelpSystem interface as well.
I'm not sure what you're referring to. I don't see any interface in my workspace called IHelpSystem and IWorkbenchHelpSystem isn't intended to be implemented. Are you referring to AbstractHelpUI? (I'm not really the help person on this team - I just felt the need to rip WorkbenchHelp apart and Nick was kind enough to let me do it ;)
Sorry, my fault - I meant to say 'IWorkbenchHelpSystem'. Since this is the interface that users will be talking to from 3.1 for their help needs, it has to have this 'init' method. The implementation of it will in turn take the registered help system class that extends AbstractHelpSystem and call it's 'init' method. Since help system providers extend AbstractHelpSystem and it is around from 3.0, we cannot just add an abstract method to it - we should provide an empty implementation that subclasses can override. Eclipse help system implementation will call indexer if needed. Other help systems can choose to do other things.
What I don't understand is why the method needs to be exposed on IWorkbenchHelpSystem. We could simply call init on startup on the users behalf.
That would be ideal, but that would mean that you are going to load AbstractHelpSystem every time to do it. By exposing the API in IWorkbenchHelpSystem, you delegate the decision to do this to the user. There should be a better way - some flag that you can check and never load AbstractHelpSystem if you don't need to.
I'm leary of adding API to a call-only public interface that typical clients would never need. Your idea of a preference is a good one. Perhaps we could expose it in the UI so SDK users who did want the preloading could have it.
Dejan, who do you anticipate should call IWorkbenchHelpSystem.init? Regular plug-ins, or the application/advisor? From the point of view of an implementor of AbstractHelpUI, is the expectation that init() would always get called before the other methods? AbstractHelpUI represents the help user interface, not core level plug-ins like org.eclipse.help that provide the help content model. I'm assuming indexing is done at core level (I guess it's actually in-between with Lucene in our help system.) Do we really want to be activating a heavyweight set of plug-ins like Help UI at startup time? Is there any reason why you can't use the existing org.eclipse.ui.startup extension point? The Automatic Update Scheduler uses this.
Indexing needs org.eclipse.help.base and org.eclipse.help, no org.eclipse.help.ui. A new plug-in that depends on org.eclipse.help.base and org.eclipse.ui, could be created and extend the org.eclipse.ui.startup point. I think there would not be any difference if org.eclipse.help.ui extends the startup point and is activated, instead of a new plug-in. org.eclipse.help.ui has a dependancy on appserver, but would not call it. I assume products have a way to disable startup by overriding preferences, so there would still be in control over eager indexing, without a need for any code. UI could ship the default default to not start org.eclipse.help.ui if we do not want automatic indexing in the Eclipse Platform, but I think we should index at the startup. Dejan, could we do this, for start and see whether it works well or there is a real need to change APIs or create new plug-ins?
> I assume products have a way to disable startup by overriding preferences Not really. We allow users to turn off startup items, and keep that stored as a pref, but it's not exposed as an API pref. (See IPreferenceConstants.PLUGINS_NOT_ACTIVATED_ON_STARTUP)
But, bugzilla does not let me erase my comment that based on the wrong assumption. :-) May be the prefernece could it be fixed somehow? I think the preference is valuable as a public APIs irrespective of help indexing. More people could start using this extension point, if the product had a final say.
Ok, let's backtrack a bit. This is the problem we want to solve: 1) Indexing can be time-consuming, particularly in large Eclipse-based products 2) Although we added the capability to ship with the pre-built index, large number of different product offerings can make this hard to use. 3) Users will hit the indexer the first time they want to search. It can be very frustrating to wait it out. 4) We (Eclipse SDK) don't want to start the help system on startup to check if indexing is needed. 5) Large products may elect to do so by providing their own plug-in that implements 'startup' extension point. However, they don't have a way of making the help system start the indexer - hence the proposed 'init' method. Obviously, we would not need the API if Help provides the small plug-in in question. What we can do is create the plug-in but not include it in Eclipse and make it available for products to include if they want the indexer to run as a background job on startup. Obviously, products that would be interested in this kind of arrangement would be the very large ones where indexing takes too long. Eclipse SDK indexing is tolerable - not slow enough to justify the startup plug-in. Now that we have defined the problem, what do you vote for?
Will consider a solution for M6.
Canceling the request. We will try to solve the indexing issue in a way that does not involve indexing on startup.
Marking as verified to reduce clutter in bug list.
