-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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). 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/ iEYEARECAAYFAkr2lNQACgkQNL8k5A2w/vzVcwCgojEm/YcKk6HZ+PCiF3j20KLy GGEAnRJqxzBvz3gvahfnSH3cTCIki1Jq =Z4IF -----END PGP SIGNATURE-----
