Skip to main content
Jump to: navigation, search

Difference between revisions of "Equinox p2 Filters"

(New page: The Equinox Provisioning mechanism needs the ability to filter and select what gets installed. This page contains some rambling thoughts on filters. === Different reasons for filteri...)
 
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
The [[Equinox Provisioning]] mechanism needs the ability to filter and select what gets installed. This page contains some rambling thoughts on filters.
+
[[Equinox p2]] needs the ability to filter and select what gets installed. This page contains some rambling thoughts on filters.
 
+
  
 
=== Different reasons for filtering ===
 
=== Different reasons for filtering ===
Line 19: Line 18:
 
metadata as a dependency graph, filters can be defined on edges and/or on nodes:
 
metadata as a dependency graph, filters can be defined on edges and/or on nodes:
  
# Node filter. Filter defined directly on the IU. This satisfies use 1) above. For 2), we need to be able to define the available properties on the node level.
+
# Node filter. Filter defined directly on the IU. This satisfies use 1) above. This doesn't work for 2), because different consumers may want to apply filters different.
# Edge filter. Filter defined on an IDependency. This doesn't make sense for reason 1) because it exposes producer implementation details on the consumer.
+
 
 +
# Edge filter. Filter defined on a RequiredCapability. This doesn't make sense for reason 1) because it exposes producer implementation details on the consumer. However, it's useful for case 2).  Each "edge" would have filters of form (key=value), where a match will result in the edge being traversed during an install.  The filter is evaluated against an environment that is passed down from the producer. Each producer on the route to an edge can alter the environment (think dynamic scoping).  Since multiple producers can define a requirement on the same downstream IU, each IU may be visited multiple times with different filter environments.
  
[[Category:Provisioning]]
+
[[Category:Equinox p2|Filters]]

Latest revision as of 15:36, 1 October 2007

Equinox p2 needs the ability to filter and select what gets installed. This page contains some rambling thoughts on filters.

Different reasons for filtering

There are various reasons why we need filtering capabilities:

  1. Filters based on properties of my installation environment.
    • os, ws, nl, arch
    • It makes sense to specify these filters directly on the affected IU Often this is an implementation detail of the producer, and is not a concern for a consumer (group). Today perhaps core.resources requires win32, and tomorrow perhaps it will not.
  2. Filters as a way slicing up functionality (core, UI, doc, help, etc)
    • It is the producer's role to define what slices are available
    • It is the consumer's role to decide what slices they want
    • A consumer higher in the dependency chain may want to override a decision made lower down in the chain.
    • A consumer higher in the chain may want to constrict/simply the set of choices available lower down

Different ways to implement filters

There are different ways of exposing filters in the metadata. If you think of provisioning metadata as a dependency graph, filters can be defined on edges and/or on nodes:

  1. Node filter. Filter defined directly on the IU. This satisfies use 1) above. This doesn't work for 2), because different consumers may want to apply filters different.
  1. Edge filter. Filter defined on a RequiredCapability. This doesn't make sense for reason 1) because it exposes producer implementation details on the consumer. However, it's useful for case 2). Each "edge" would have filters of form (key=value), where a match will result in the edge being traversed during an install. The filter is evaluated against an environment that is passed down from the producer. Each producer on the route to an edge can alter the environment (think dynamic scoping). Since multiple producers can define a requirement on the same downstream IU, each IU may be visited multiple times with different filter environments.

Back to the top