On 11/8/2009 7:40 PM, Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/8/09 2:52 AM, Peter Saint-Andre wrote:
My apologies again for the delayed reply.
On 10/8/09 8:31 PM, Brett Zamir wrote:
On 10/7/2009 11:14 AM, Brian Cully wrote:
On 4-Oct-2009, at 23:47, Brett Zamir wrote:
On 5/18/09 4:39 PM, Peter Saint-Andre wrote:
On 5/15/09 3:57 PM, Brian Cully wrote:
In my world, subscription option defaults are better left
relegated to a
node, as nodes may then be able to calculate appropriate defaults
based
on their semantics, which may be different from node to node within a
given pubsub service.
That does seem more reasonable: you ping the node for default
subscription configuration options and you ping the service for
default
node configuration options.
Sorry to take quite a while in response to this. While it is fine to
be able to get node specific subscription defaults, I still think it
would be nice to have a service-wide default (of lower priority than
a node-specific one, of course): one for leaf nodes and another for
collection nodes. Could an attribute "type" be added of value "leaf"
or "collection" to be used when the "node" attribute is not used on
<default/>?
What does "type" mean in the context of subscription options? You
subscription options will not magically change a node from a
collection to a leaf node or vice-versa.
I meant for use with a service-wide default--not for node-specific
queries. Services may tend to make available one set of subscription
options for collection nodes and another for leaf nodes if they are not
making exceptions for individual nodes.
My interest to see this is so that the client can work off of a
general default in submitting subscription requests, saving the
service's default so that the user can submit their options for new
subscriptions without having to retrieve the node-specific options,
but while still having an idea about the available options and being
able to base their own preferences off of such a default.
You can only subscribe to a specific node. Nodes already have
default subscription options which can be queried. Options that may be
wildly different based on that particular node's semantics, I might
add. Thus there is absolutely no gain in offering "default defaults"
because such a thing doesn't even make sense on its face.
Default options don't make sense if each node has its own distinct
options (well, actually it could if exceptions were rare, but I'm not
seeking this), but that is not necessarily always the case. One may wish
(as we do) to allow nodes within a service to offer the same
subscription options across all leaf nodes or collection nodes in the
service, respectively, and allow clients to discover and retain this
information so that users who come across a new node can immediately
choose how to subscribe to that node without making an additional
node-specific query.
OK. But it is also possible (perhaps not in your deployment) for each
node to have different defaults for subscription options, right? I'm
trying to think about how best to handle that. Perhaps it doesn't make a
lot of sense to have default subscription options on a per-node basis,
only service-wide (or, as you say, one set for leaf nodes and another
for collection nodes). I'd be inclined to specify that and avoid the
mess of per-node defaults (since you'd need to query each node before
attempting to subscribe, which doesn't save you anything).
I think we can do this simply by leaving off the 'node' attribute....
<iq type='get'
from='[email protected]/barracks'
to='pubsub.shakespeare.lit'
id='def2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<default/>
</pubsub>
</iq>
Yes, as far as I can tell, I agree it dosn't make sense to have
different defaults per node, as querying that would be wasteful.
However, should we still add a "type" attribute or the like on
<default/> to specify a default as to whether it was a collection or
leaf node? For example, in PubSub Collection Nodes,
pubsub#subscription_type and pubsub#subscription_depth might have their
own defaults but only for collection nodes. Likewise might one wish to
have leaf-node-only subscription defaults (e.g., Openfire's
implementation has "x-pubsub#keywords" exclusively for leaf nodes
subscription options).
Brett
