-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/9/09 9:39 PM, Brian Cully wrote:
> On 8-Nov-2009, at 07:19, Brett Zamir wrote:
>> 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.
>
> Requiring a node parameter in <default/> when node-specific defaults
> are required is an acceptable amount of waste, IMHO.
Agreed.
>> 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).
>
> What about pubsub#expire, which can be expected, in some instances,
> to have different defaults depending on node? I don't want to see a
> proliferation of attributes on the request, particularly when they can
> already be satisfied with one that already exists ("node").
It's not clear to me which attributes are fundamental enough to force
the use of a different set of defaults. I can see it for leaf vs.
collection. But there also might be different defalts for nodes that do
presence-based delivery, etc. Pretty soon, the concept of a default
might be close to meaningless. :)
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/
iEYEARECAAYFAkr4e5cACgkQNL8k5A2w/vzJsQCg9eXZ+3WtGN0sq/BTp6FTBJAN
MDAAn3+4VULEpmE8g0p0HQTL2DhM0jj1
=0u9+
-----END PGP SIGNATURE-----
