Hi all, I've had a good chat with Ian on this.
First of I want to restate the issue: the publisher wants to publish an item to a node that has a certain access model. There are two ways to solve this: 1. No auto create. In this case, there is no magical node creation on publish. A publish to a non-existing node fails, the client will create a node with the desired configuration and then republishes. 2. Auto create. Here, as long as all nodes are to be created equal, with the default configuration, all is well. However, if you are having a service that hosts both extended presence nodes and private access nodes, you will want to have different configurations for the nodes that are created automatically on publish. Obviously you can check before each publish, but that is undesirable for various reasons. That leaves us with some variation on the theme below. Comments in between and conclusion at the end. On Fri, 2007-07-06 at 14:19 -0600, Peter Saint-Andre wrote: > Ian Paterson wrote: > > Peter Saint-Andre wrote: > >> Whenever a client publishes the first item to a node that ends in > >> "+[accessmodel]", the pubsub service MUST create the node with a default > >> access model equal to the specified model (that is "open" or "presence" > >> or "roster" or "authorize" or "whitelist"). [1] For such a node, the > >> access model MUST remain fixed and a pubsub service MUST return an error > >> if the node owner tries to change it. > >> > >> [1] In fact "roster" doesn't make sense here since you need to specify > >> the roster group. And BTW the list for "whitelist" must start out empty, > >> i.e., only the node owner can publish or subscribe. > > > > I think I agree with everything above except the proposed syntax. *If* > > we agree on the functionality, then IMHO it *should* be trivial to come > > up with a more appropriate syntax. > > > > I strongly disagree with overloading the node attribute with the access > > model. IMHO, mixing an identifier and a configuration parameter into the > > same attribute would be a horrible (and unnecessary) hack. > > One nice thing about the NodeID hack is that the client knows > immediately what the access model (e.g., if the node already exists and > it receives data published to that node by another resource). But it is a hack and one-trick pony. > > Instead of: > > <publish node='http://jabber.org/protocol/activity+whitelist'> > > > > I could live with this syntax: > > <publish node='http://jabber.org/protocol/activity' > > access_model='whitelist'> > > Haven't we been down this road before? See for instance Example 5 here: > > http://www.xmpp.org/extensions/attic/jep-0163-0.2.html > > Yet we moved away from that. See here (Ralph objecting to the 'access' > attribute): > > http://mail.jabber.org/pipermail/standards/2006-May/011315.html > > And further discussion: > > http://mail.jabber.org/pipermail/standards/2006-May/011383.html > http://mail.jabber.org/pipermail/standards/2006-May/011414.html > http://mail.jabber.org/pipermail/standards/2006-May/011417.html > http://mail.jabber.org/pipermail/standards/2006-June/011496.html > http://mail.jabber.org/pipermail/standards/2006-June/011572.html > > This is essentially publish+configure all over again, but limited to the > access model. Yes. I opposed the 'access' attribute and would again. > > However, IMHO, the following example stanza would "fit" better with the > > rest of the protocol. That would make it easier for developers, since > > they could simply reuse their existing <configure/> element processing > > code: > > > > <iq from='[EMAIL PROTECTED]/balcony' type='set' id='create-presence'> > > <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 nurse's birthday!</text> > > </activity> > > </item> > > </publish> > > <configure> > > <x xmlns='jabber:x:data' type='submit'> > > <field var='FORM_TYPE' type='hidden'> > > <value>http://jabber.org/protocol/pubsub#node_config</value> > > </field> > > <field var='pubsub#access_model'> > > <option><value>whitelist</value></option> > > </field> > > </x> > > </configure> > > </pubsub> > > </iq> > > > > I stress that the functionality associated with the above example would > > be absolutely identical to that which Peter described above. > > Right. > > It's publish+configure. Again. Do you think we'll make more progress > this time? We might. I still oppose the idea of publish+configure because it is not what it seems. What we want is this: on publish, if the node exists, only process the request if the node has this access model, or, if the node does not exist, create a node that has this access model. So whatever you would add to the request, doesn't actually (re-)configure the node. It is some kind of precondition for the publish request to succeed. The auto node creation is a side effect. But having the one-trick pony of an attribute for the access model feels icky to me. What if we do allow the publisher to attach a form with 'publishing options', 'publishing conditions', or whatever we want to call them? Something not called <configure/>. For now we would only have a check on the access model in there. But it does leave the door open for future enhancements. Ian seemed to agree on this idea. I do want to note that prefer 1) from above more, but if we have 2), like we do now, I think this is the next best thing. -- Groetjes, ralphm
