[Standards] private storage revisited

Ralph Meijer jabber.org at ralphm.ik.nu
Fri Jul 6 21:05:17 UTC 2007


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='juliet at capulet.com/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




More information about the Standards mailing list