Joe Hildebrand wrote:
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.
Oh, I thought you meant the subscribe, not the notify.
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.
Well if I'm going to send presence to the groupchat service I might like to receive presence in return (what if the service goes offline?). I see this as similar to sharing directed presence in a one-to-one chat with someone who's not in your roster. But I suppose there's no guarantee that the service will reciprocate.
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.
"One small step for clients, one giant step for the network."Explicit subscribe would still require changes to lots of components, but the changes would not be as significant in scope as adding PEP everywhere.
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.
Heh, true.
I'm still pondering. :)Me too.
Another consideration is that a newly-connected client might send a very large number of service discovery requests. E.g., I have 1711 people in my roster. Will my client send a service discovery request to each one? If so, will include the <subscribe/> in each one? I don't see how it will determine whether to include the <subscribe/> (it can't do so based on the service discovery identity because we're saying that it might want to include the <subscribe/> in the disco#info request) so I assume it will do so in every request. Is that acceptable? Or is it better to go the PEP route? (Yes, there is more work involved on the component side, but clients can be relatively dumb yet get this functionality at a low cost. Perhaps there could be code re-use from servers that do PEP to components that want to. And this moves us a step closer to things like PEP in chatrooms.)
As I mentioned, it seems to me that we already have caps for dynamic communication of disco#info data. In my experience it's disco#items where we have the gap (the main use case I've heard about is wanting to find out about newly-created chatrooms at a groupchat service, but there may be others).
But I'm still pondering... :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
