Michael Jakl wrote: > Hi! > > I've started with the disco(very) implementation yesterday. There seem > to be two possible ways of implementing disco, and the pubsub > extension at large. > > The Pubsub Module is a subclass of DefaultDiscoAwareModule, which > provides three method-stubs to deal with disco: > - addInfoRequestListeners > - addServerInfoRequestListeners > - addItemRequestListeners > > The ServerInfoRequest is for server-features. The Pubsub module could > identify the server addtionally as pubsub service. Meaning we have an > additional "identity" and "feature" element (see XEP-0030 3.1[1] and > XEP-0060 5.1[2]).
This is the way to go. > The InfoRequest returns the disco information for a particular node. > The Pubsub module could be addressable by its own JID inside the > server. "pubsub.vysper.org" or something. Not quite. 'pubsub.vysper.org' is a completely different /domain/ than 'vysper.org'! There is no inclusion relationship defined for xmpp domains related to domain names. so the "pubsub.shakespeare.lit" in the spec is equivalent to 'vysper.org'. > The difference between ServerInfoRequest and InfoRequest is, that the > server has either no "to" JID or no node associated (and the > server-entity matches the to address). > > The ItemRequest (for completeness) returns either the associated nodes > (service) or all items (node). > > The question thus is, should I "enhance" the server with the pubsub > service, or provide an additional entity within the server? I tend > towards the first option, but I'm not quite sure. What would you > suggest? How would implementing the second option make the pubsub feature discoverable? There'd have to be a kind of redirect from vysper.org to pubsub.vysper.org, which doesn't exist, AFAIK. Is that answering your question? Bernd
