-----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>
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr2rkEACgkQNL8k5A2w/vyIwQCfdBZsSOdna+NMruVbasOXjJzi
yRYAoIELRqBhJqYdsoKI+xlvpXwOWCD6
=OkJu
-----END PGP SIGNATURE-----
