Hi! On Tue, Jul 7, 2009 at 12:06, Bernd Fondermann<bf_...@brainlounge.de> wrote: > Michael Jakl wrote: >> Currently it should (why not?), but as soon as we allow components to >> have different domains it doesn't anymore. > > That's what I had in mind. What if the pubsub is addressed as > pub...@domain.org, wouldn't this trigger a problem already?
Very likely. I was planning to address pubsub nodes as domain.tld with a node attribute. This is also conform to the disco requests. The spec calls pubsub nodes addressable as u...@domain.tld "virtual". To support addressing using this schema (without big changes), we'd have to introduce a virtual user acting as the pubsub service... . >> Anyway, the JID for the module should be configured elsewhere, and not >> take from the request. I'll fix that too tonight. > > +1. > > In a related thought, what do you by the way think about introducing a > PubSubConfiguration class where all of the many options possible in > pubsub can be collected? The module JID could be one of them. The pubsub module doesn't have that many configuration options as far as I can see. Most of the options are related to LeafNodes, but I'll keep it in mind. Concerning the options (together with disco): Somehow I'd like to separate the collection of the possible options out of the disco-part (currently all supported features have to be put into one class). Something like going through all handlers and collection whatever features they support would make many things much easier. I think this is exactly what you do with the handlers (which handler is responsible for which kind of request). But that's more or less future talk. Michael
