[Standards-JIG] JEP-0060 (pubsub) node configuration

Ralph Meijer jabber.org at ralphm.ik.nu
Mon Jan 3 20:42:18 UTC 2005


On Mon, Jan 03, 2005 at 01:12:24PM -0700, Peter Millard wrote:
> On Mon, 3 Jan 2005 20:32:35 +0100, Ralph Meijer <jabber.org at ralphm.ik.nu> wrote:
> > I would suspect that leaf nodes and collection nodes might have different
> > configuration options. It seems to me that there is no way to ask for the
> > default configuration of a certain type.
> 
> I'm not sure what you mean here.. could you clarify or re-word this?

I'll try by example. A leaf node could have configuration options that
don't make sense for a collection node. For example pubsub#persist_items
or pubsub#publish_model. On the other hand, pubsub#node_type would be
used in the config form that is sent along with node creation to determine
the type of the node being created (leaf or collection).

My interpretation of the spec is that a client would first ask the service
for a configuration form (iq-get with a <configure/> element), so that
the client can present it to the user and, upon completion by the user, send
the form along with the create request. Now, when implementing collections,
such a form would at least contain the pubsub#node_type field, and possibly
others.

My point is that requesting the 'default configuration' in this way might
also be used to determine the actual default configuration of a node so
that this could be accepted as the default without sending the <configure/>
element along with the create request. This is worded as such in the
second paragraph of 8.2.2.

So what to do with options like pubsub#persist_items? It doesn't make sense
when creating a collection node. As far as I know there is no way (yet)
to have fields be conditional (that is, depending on the value of other
form fields). An implementation might choose to only put options in the
form that are common to both collection and leaf nodes, but then the
client has no way of knowing the node-type-specific default configuration
options.

> > Also, if the root node has an NodeID that is empty, how can I configure this
> > node? It seems to conflict with requesting a default configuration form.
> 
> I was under the assumption that the root node would have static
> configuration, or be fixed based on the implementation and would never
> be configured online (via protocol).

Hmm, right. I was thinking of options like disabling disco#items on certain
collection nodes. The root node would be most appropriate for having such
an option.

> > Another point that came to mind was that there might be configuration options
> > that would only make sense on node creation time, like the choice for having
> > a leaf or collection node. Could an implementation choose to send a different
> > config form after node creation?
> 
> I think most implementations will send different forms. After
> creation, the config form may have some static fields like date/time
> of creation, creator, etc.

How does a client know this? It seems to me that the 'fixed' field type
was not meant for this use (reading JEP-0004) and that there is no other
way to represent a field as being static.

I had thought a service would only sent a form (after node creation) containing
the fields a client can actually change. For seeing the static data, the
more complete form can be retrieved using disco#info's meta-data attachment.

-- 
Groetjes,

Ralphm



More information about the Standards mailing list