Ian Paterson wrote:
> Peter Saint-Andre wrote:
>> We already have one such solution/hack in PEP: the +notify
>> namespaces used in entity capabilities to signal that a subscriber wants
>> to receive notifications related to a given namespace. Your suggestion
>> of +whitelist (etc.) is in the same spirit, but +notify does not force
>> semantic structure on NodeIds, which +{access_model} does (and the
>> objections may arise because NodeIds are supposed to lack semantic
>> structure).
>>
> Yes, there is a significant difference between "+notify" (where the var
> attribute of the <feature/> element continues to specify only the
> functionality that the client supports), and "+{access_model}" (where
> the 'node' attribute of the <feature/> element no longer simply
> identifies a node, i.e. it is overloaded to also specify the
> configuration of the server).
>
> That said, we still might want to consider defining a new notify='true'
> attribute for disco#info <feature/> elements. Disco is "Final", but this
> change would be 100% backwards compatible, and is therefore permitted.
> What do people think?I don't have a particular problem with the +notify stuff, myself. And it makes the PEP notification filtering go quite smoothly. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
