[INFOD-WG] Dynamic consumer constraints

[Fisher, SM (Steve)]

> -----Original Message-----
> From: infod-wg-bounces at ogf.org 
> [mailto:infod-wg-bounces at ogf.org] On Behalf Of Dieter Gawlick
> Sent: 12 July 2007 22:55
> To: INFOD
> Subject: [INFOD-WG] Dynamic consumer constraints
> 
> All line references are from the published Base INFOD 
> Specifications - see Current Documents folder
> 
> Property Constraints (line 991) are used to derive Consumer 
> Entry References (line 1788); Dynamic Consumer Constraints 
> are past along to publisher in the Dynamic Consumer 
> Constraints (line 1791).
> 
> The specifications do allow that both types of constraints 
> are specified concurrently, they do not say what the 
> combination means. So, one possibility is to say: If both 
> constraints are specified all messages go to consumers listed 
> in the Consumer Entry References and additionally to the 
> consumers that fit the Dynamic Consumer Constraints. Both 
> entries and the Registry notification to the publishers are 
> used. If we would like the Registry to provide the set of all 
> possible consumers (for the Dynamic Consumer Constraints) we 
> would have to add an entry in the notification.

That would be a bizarre reading of the spec. It makes no sense for one
constraint to be able to weaken another. Each time a new constraint is
imposed the total messge flow can be reduced but not increased. This
should be spelled out a little more clearly in section 1.1.1.4

> Calculating this list, however, seems to create fundamental 
> problems; it may be very big and more importantly the 
> registry may not understand the constraints because these 
> constraints are referencing data vocabularies, which do not 
> need to be XML vocabularies. So far, we avoided the registry 
> to get involved in evaluating non-XML constraints.

This is something I wanted to define in the spec but was persuaded not
to. I think we either have to specify a plugin mechanism for a vocaulary
or define a vocabulary as a service. I much prefer the latter approach.
Meanwhile our spec does not, in practice, support non-XML data
vocabularies. This should probably be stated.

> We could also say that property constraints limit the 
> eligible dynamic consumers; but this would have to be made 
> very explicit.

We have always said that constraints are cumulative - I see no reason
for this to be an exception

> I recommend not to calculate the list of potential consumers 
> and clarify the specifications in this respect.
> 
> If we go this direction we do not have a solution for the 
> publisher to become aware of new consumers for an existing message. 
> 
> However, here is a proposal for future versions: We specify 
> that the registry has to support CQs (Continuous Queries). If 
> a publisher likes to be informed about new consumers with a 
> set of properties the publisher has to write a CQ against the 
> registry. Obviously, we could also say that the registry has 
> to accept subscriptions - CQs and subscription seems to be 
> very closely related. We already had this in the 
> specifications and removed in the NY F2F since we felt that 
> the implementation is too difficult.
> 
> Dieter
> 
> -- 
> 
> 
> Oracle Email Signature Logo
> Dieter Gawlick | Architect | 650.506.8706
> Oracle Server Technologies
> 500 Oracle Parkway | Redwood Shores, CA 94065 
>