Michael Jakl wrote: > Hi! > > On Tue, Jul 7, 2009 at 12:06, Bernd Fondermann<[email protected]> 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 >> [email protected], 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 [email protected] "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.
When I read the spec, I just thought at multiple places: Oh, that should go into a config option! But I never kept a list of those, unfortunately. > 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. +1 > > Michael
