Mridul Muralidharan wrote: > Peter Saint-Andre wrote: >> I understand handling of fields that are preconditions, it's what we >> outlined before: >> >> 1. If the node exists and the precondition is not met (in this case, if >> the access model is something other than "whitelist"), then the publish >> fails with a suitable error condition (probably <conflict/> along with >> some pubsub-specific condition). >> >> 2. If the node exists and the precondition is met, then the publish >> succeeds. >> >> 3. If the node does not exist, then the service auto-creates the node >> with default configuration in all respects except those specified in the >> preconditions (in this case, the node would be created with an access >> model of "whitelist") and the publish succeeds. >> >> What other field types do people envision for publishing options? Here >> are some possibilities: >> >> - publish this item with the specified metadata >> >> - publish but override node configuration for this item only (yes this >> would enable per-item access controls, but let's not talk about that too >> loudly and maybe people won't notice... ;-) >> >> Naturally it's up to the implementation or deployment whether it >> supports any of these field types. >> > > A means to specify, dont publish if precondition is not met - a means to > use it as config assertion.
Isn't that precondition? See point #1 above. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
