Re: [Standards] private storage revisited
Ian Paterson wrote: Wow! consensus on Personal Publishing! I'm off to celebrate :-) :-) Well, so far only a consensus of 3 people who disagreed in the past. - Ian
Re: [Standards] private storage revisited
Sigh. One of the goals of PEP was that it was supposed to be easy to implement on the clioent side. On 7/8/07, Mridul Muralidharan [EMAIL PROTECTED] wrote: Ian Paterson wrote: Peter Saint-Andre wrote: So we'd have something like this: iq from='juliet at capulet.com/balcony' type='set' id='foo' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='http://jabber.org/protocol/activity' item activity xmlns='http://jabber.org/protocol/activity' relaxing partying/ /relaxing text xml:lang='en'My nurseapos;s birthday!/text /activity /item /publish preconditions x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field field var='pubsub#access_model' optionvaluewhitelist/value/option /field /x /preconditions /pubsub /iq 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). If the node exists and the precondition is met, then the publish succeeds. 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. Correct? Correct. +1 Thank you Ralph, Peter. Wow! consensus on Personal Publishing! I'm off to celebrate :-) :-) - Ian Whether to autocreate or to return error saying node does not exist (item-not-found) - can this be an implementation detail ? That is, are clients expected to handle the error path too and explictly create ? We do not have auto create in pubsub iirc (not sure if pubsub was modified to support this) - so supporting this for pep will implictly mean supporting it for pubsub too (same namespace, etc). But in general, preconditions are great way to assert access level for clients/nodes which require strict acl's. Regards, Mridul PS : Hope this is not going back to the same path's earlier, just wanted to get it clarified. -- Joe Hildebrand
Re: [Standards] private storage revisited
Mridul Muralidharan wrote: Whether to autocreate or to return error saying node does not exist (item-not-found) - can this be an implementation detail ? That is, are clients expected to handle the error path too and explictly create ? We do not have auto create in pubsub iirc (not sure if pubsub was modified to support this) - so supporting this for pep will implictly mean supporting it for pubsub too (same namespace, etc). In accordance with earlier Council discussion, we have provisionally moved all the substantive features to XEP-0060 (so that things like PEP are simply profiles of various features defined in XEP-0060). The auto-create feature is describe here: http://www.xmpp.org/extensions/tmp/xep-0060-1.10.html#publisher-publish-autocreate Support for the auto-create feature is optional. If a service supports that feature then it would auto-create, if not then it would return item-not-found. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] private storage revisited
Joe Hildebrand wrote:
Sigh. One of the goals of PEP was that it was supposed to be easy to
implement on the clioent side.
True. Unfortunately, one of the features of the XSF standards process is
that it's based on consensus, with Council approval for changes to Draft
standards. In this case, that seems to be moving us away from a simple
solution (one person's beautifully simple solution is another person's
evil hack). 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).
I agree that this solution lacks elegance. But given it may be the best
we can do.
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
