Community
Participate
Working Groups
Currently if you store some doc plugins on a remote help server, then get a client to point to it, the client will see all documentation available even if the client doesn't have that component. There needs to be a way to associate doc plugins with UI so that the client can only show what is relevant.
John, Dejan, I've updated the remote help proposal with a new extension point for the mapping of help plug-ins to plug-ins they are documenting: http://www.eclipse.org/eclipse/platform-ua/proposals/help/remote_help/proposal.html See the scope section. Please provide feedback in this bug.
Curtis, I see what you wanted to achieve but am concerned regarding the extra extension point. As a matter of fact, we have two filtering issues: (1) Extra documentation that does not apply when RCPs are shipped without the entire platform bundle list (form example, an RCP without the team component that still contains it) (2) Extra documentation from the remote server Why don't we solve both problems by tagging the branches with the filtering we now have up and running? We can simply go and ask each of the documentation providers to add a filtering condition for their book node that it should only be shown when a certain bundle is present. This will solve both 1) and 2) by simply using existing mechanism. Actually, for (2) we should also tag certain branches so that they are filtered as well (say, not showing Team-related nodes if team bundles are not present). One of the reasons I would prefer that approach is that filtering would be done on the client. In some cases, users may be concerned about privacy issues since the client would be sending their entire bundle list to the server. Jim des Rivieres and myself grappled with this problem in the context of Update. There is always an issue with the client sending information about the local client's installation to the server because it can always be used for spam-related data gathering or spying. Another unrelated comment on the API: I am somewhat concerned about the shortcut you took when it comes to TOC that is expressed in XML right now. Since our original implementation uses XML, it is convenient to us to capture data as a Node but we should not leak this into what was supposed to be general-purpose interface. What I would expect would be: ITocContribution interface that makes no assumptions about the implementation NodeTocContribution as a helper class for implementations backed by an XML file Similarly, why is the document talking about ITocProvider but you immediately switch to AbstractTocProvider class instead?
Fixed. The doc plugins' tocs now have appropriate filters and will only show up when the functionality is installed locally.
