2009/8/13 Michael Jakl <[email protected]>: > On Thu, Aug 13, 2009 at 20:06, Niklas Gustavsson<[email protected]> wrote: >> On Thu, Aug 13, 2009 at 3:48 PM, <[email protected]> wrote: >>> + <!--<bean >>> class="org.apache.vysper.xmpp.modules.extension.xep0045_muc.MUCModule" />--> >> >> Please note that the MUC module will require a constructor parameter >> that sets the domain on which the MUC module will listen for stanzas. >> Also, user will probably want to add their own Conference instance >> into the constructor. > > I've the same "issue" with the pubsub module. My current approach is > to setup a module-configuration object in the initialize-method of the > module. It's not perfect, but removed the need for a constructor > parameter. > > My plan was to read some configuration file at this point. How to deal > with multiple instances of the modules is still foggy.
Well, the whole purpose of Spring is to enable being able to configure things like this, so I don't think there is a problem at all. Reading a separate configuration file from within the module seems to defeat the purpose of using Spring. So, I would say that we should allow for modules to be configured using constructor parameters or setters methods (as appropriate). > Ps: I'm wondering if the user should be able to decide whether a > module should reside on a subdomain, or if it should integrate with > the server on the same domain. With our current approach it's up to > the module. > Is there a way to keep the module simple and still allow both ways of > registering within Vysper? In some cases, like the MUC module, it is required to run on a subdomain (as per the spec). In that case, I would recommend that the module takes the subdomain as a constructor parameter and then adds a SubdomainHandlerDictionary has the only HandlerDictionary. If a module supports both ways (a spec which contains namespace extensions elements in all stanzas) the subdomain constructor parameter can be made optional. Should the user have set it, the module would register a SubdomainHandlerDictionary. If not set, it instead registers a NamespaceHandlerDictionary. If the module is intended to extend the server on the main domain, it would only register NamespaceHandlerDictionary. Makes sense? To enable these scenarios was the background to why the sub domain patch was designed as it was. /niklas
