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.
Brett
