On Jan 7, 2008, at 10:53 AM, Peter Saint-Andre wrote:
I would expect that to only be there if the original request had a
node (in the disco sense) in it. The node is required in the
XEP-60 schema, so there has to be something, but it would be nice
to be able to distinguish the "no node" case from a disco publish
(see section 5 of XEP-30).
I think the MUST in XEP-0060 is a spec bug, because when you
subscribe to the root collection node you don't include a 'node'
attribute.
I'm not sure. Notifications there come in a collection tag, not an
item tag.
Looking at the proto-xep this morning, I realized that I think we
should allow this for disco#info as well. The use case is that the
admin reconfigures a component at run time with connected clients.
Isn't disco#info handled by caps? It *could* be handled by this
mechanism if presence isn't shared, but we're assuming that presence
is shared.
You often won't get caps from a component. I'm imagining that I want
to get the disco#info of a groupchat service, and get notified when
the admin modifies the config. I never did get presence from the
groupchat service.
On the implicit/explicit bit, after thinking about it some more, I
really don't want to have to implement caps in all of the
components that are going to use this.
Simple clients, complex servers?
Small change to clients that have to be modified, large change to lots
of different places in servers, including caching, hashing, and state
management.
I can't think of a way to have both, either, since you would have
to include the explicit subscription in all requests;
What might break if clients (and other entities) start including the
<subscribe/> element in all their disco query requests? I suppose
we'll find out (and any responding entity that breaks has a bug,
since it must ignore elements it doesn't understand according to RFC
3920).
+1. The biggest issue I would expect is programs that expect the
query to be empty swapping to/from, and adding to the existing query
element. In that case, you'll receive the subscribe element back,
which is why I'm glad that we look for "subscription" in the response.
I'm still pondering. :)
Me too.
--
Joe Hildebrand
