Community
Participate
Working Groups
First, it might be worthwhile to add an additional ALL related constant that would just include everything in the osgi.wiring.* namespace. Second, it might be helpful to be able to use the current ALL constant but then weed out some namespaces I know I don't want. This is essentially the "I want everything but..." case. This could be done, for example, by adding a series of RegionFilter.reject methods. Users could then do something like this. builder.allowAll(VISIBILE_ALL_NAMESPACE).rejectAll(VISIBLE_BUNDLE_NAMESPACE)
(In reply to comment #0) > First, it might be worthwhile to add an additional ALL related constant that > would just include everything in the osgi.wiring.* namespace. > I don't think this is particularly interesting or that useful. You would be missing all the generic capabilities with no easy way of allowing all of them. > Second, it might be helpful to be able to use the current ALL constant but then > weed out some namespaces I know I don't want. This is essentially the "I want > everything but..." case. > > This could be done, for example, by adding a series of RegionFilter.reject > methods. Users could then do something like this. > > builder.allowAll(VISIBILE_ALL_NAMESPACE).rejectAll(VISIBLE_BUNDLE_NAMESPACE) I think the reject style is more useful. Right now the allow methods basically append the filters as a list of ORs. If we added the reject methods then we would have construct a filter that OR'ed all the allow filters together and then AND'ed that with another NOT filter that OR'ed all the reject filters together. Unfortunately such a change makes the method org.eclipse.equinox.region.RegionFilter.getSharingPolicy() awkward. This method returns a Map<String, Collection<String>> with namespace as the key and the value a Collection of allow filter strings. I am not sure how we express the reject filters from this method. This also impacts the persistence of the digraph.
If we went this route I think org.eclipse.equinox.region.RegionFilter.getSharingPolicy() would need to be deprecated and replaced with: RegionFilter.getAllowPolicy() RegionFilter.getRejectPolicy() Both which return a Map<String, Collection<String>>. For something to be allowed by a RegionFilter it would have to be matched by the allow policy and not by the reject policy. The implementation of the deprecated getSharingPolicy would simply return the result of getAllowPolicy.
Doubtless all sorts of extensions could be made to the region digraph, but I think it is important to keep the code minimal and drive it by actual use case. Based on the two occurrences of "might" in the original description, I advise deferring these features until they are actually needed. In particular, there are other features, such as graph optimisations, which might be considerably complicated by adding negative terms into the filter structure. These features are also in the category of "might be needed", but could become important if we hit performance problems. If there are important reasons for implementing these features, it would be good to give graph optimisation a little more thought first. I did a bit of this analysis a few months ago, and the current filter structure seemed to lend itself to being optimised nicely because each path through the graph is essentially already in conjunctive normal form (an AND of a series of ORed terms). Combining multiple paths then permits optimisations like the following: (p && (q || r)) || (p && q) = p && (q || r || q) = p && (q || r) Having said that, I don't *think* these features make opportunities for optimisation less likely, but they could complicate the analysis and so they come with a cost. Hopefully, this gives more food for thought as we consider whether to implement these features...
No plans to make this change.
