Community
Participate
Working Groups
This is a more general version of the question posed in bug #209541. I'm not quite sure I understand when something is a capability of an IU and when it is a property. The specific case I have in mind is "group" IU's. A group is an IU who provides a capability whereby IInstallableUnit.NAMESPACE_IU_KIND is "group". On the other hand, a rollback profile IU is an IU whose PROP_PROFILE_IU_KEY property is true. I am implementing category IU's and started down the path of defining a PROP_CATEGORY_IU property. Should I instead be defining a category similarly to a group, using a namespace?
A related concern, or perhaps part of the answer: If something is a capability, then I can use the IQueryable interface to get only those things meeting the capability. So, for example, I can query the group IU's directly from the repo rather than getting all the IU's and checking whether they are groups. But I can't do the same with an IU property, which is unfortunate in some cases. So... - should category be a capability so that I can do remote queries of only the category IU's to save time when showing available IU's for install? - should IQueryable support the checking of properties?
From a UI perspective, it would be ideal if - both properties and capabilities could be queried. - a query was represented as an interface. I could always invent the query interface at the UI level and then use this to provide the right parameters to the queryable. - do we have anything to gain by querying repo managers? For example, I often only want to know about the non-implementation repos. Use cases in the UI are: - query only the category IU's - query only the group IU's - query only non-implementation repositories
John, Pascal, and I discussed this. We don't have a definitive answer for whether some of our "meta properties" (like group, category, update range) should be represented using an IU capability or an IU property. There was a time when using capabilities to represent certain properties caused problems for the resolver. This is no longer an issue. As far as "category" IU's go, we decided it makes sense to represent a category using a capability, mainly because that's how we currently represent "group" IU's, and they are similar. It's possible that the only reason a group IU was represented using a capability was to be queryable, but we aren't sure. We feel like the use of capabilities allows a bit more flexibility/indirection (such as one category or group providing the capability of another category or group, rather than relying on direct reference.) Bottom line: we haven't yet answered the question but don't feel it's urgent for M4.
We discussed this in the 11/19/2007 p2 call. We said... "Should only use a provided capability if we envision another IU having a required capability to match it. I.e., only use it for resolution. We can easily add support to IQueryable for querying against IU properties if needed." We talked about changing the group capability to a property, and if this goes well/easily, it validates this decision. Note that I'm already querying against IU properties in the UI code for categories.
Marking fixed (I assume for a bug that is a question, the answer is the fix).
I'm reopening this bug because we didn't yet convert the group capability to a property. Renaming the bug to better reflect this. Once that is done and if it goes smoothly, then I think we've answered the question.
Susan do we need to coordinate before doing that change or is your code ready for it?
There is a little coordination required. The UI defines queries for the viewer content, so we just need to change the group query from a capability query to a property query. This is in two places: ProvSDKQueryProvider - the CapabilityQuery groupQuery defined in line 57 just needs to be changed to an IUPropertyQuery as in the very next line, categoryQuery. Likewise in line 53 of ProvAdminQueryProvider.
Released. Group is now a property (IInstallableUnit.PROP_TYPE_GROUP). Also changed IU fragment to be a property rather than a capability.
