The bug database said that issues should be raised in the forums. Is this the correct forum or should it be the support forum? If so, here it is…
I noticed that the MUC interface has a few (three) dependencies on the MUC SPI. This makes it impossible to create a different MUC implementation. They are easy to spot if you remove imports to org.jivesoftware.wildfire.muc.spi.* from the org.jivesoftware.wildfire.muc.* java files.
I can provide more details, modified files, whatever if desired.
Hey Mike,
Are you creating new implementations of some MUC interfaces? Interesting, in fact we were thinking of removing all those interfaces (to simplify the model) and just keep the classes. BTW, which are the references that you found?
Thanks,
– Gato
Thanks for the response Gato.
What I would like to do is use Wildfire as a casual game server. Game flavors (e.g. chess) would be implemented as Wildfire plugins. Each instance of a game would be implemented as a MUC. And ideally, the client game implementation would be implemented as a Spark plugin. Since a game instance is basically a conference with a few enhancements, game plugins could focus on the game implementation and leverage Wildfire for all of the communications.
I thought of a number of ways to enhance the muc implementation to provide support for the game plugin, but most of them would require changes to the core implementation of Wildfire. I thought as a first pass, I would like to stay within the boundaries of a plugin. The one way I can currently do that is to duplicate the entire muc implementation in the plugin itself, then register it in place of the standard implementation. I tried this last night and it seems to work. However, in duplicating the muc implementation, I ran into those three interface gotchas.
Thanks for mentioning that the muc interface may collapse in to the implementation. One of the other implementation ideas I had would be to create a muc listener interface. A plugin could then register as a muc listener and receive muc events such as: muc created, muc destroyed, user joined, and user quit. Standard muc functionality would be managed by the core, but could be enhanced by a plugin.
I am new to this system, so I am sure there are some other, better ways. I would be appreciate suggestions from anyone.
Finally, I’'ll diff out my files and post the three modifications in my next post to this thread.
Here are the changes that I made:
org.jivesoftware.wildfire.muc.HistoryRequest
-SendHistory() first parameter changed from MUCRoleImpl to MUCRole.
-Removed spi import.
org.jivesoftware.wildfire.muc.IQAdminHandler
-Created interface.
org.jivesoftware.wildfire.muc.IQOwnerHandler
-Created interface.
org.jivesoftware.wildfire.muc.MUCRoom
-Removed both spi imports.
org.jivesoftware.wildfire.muc.spi.IQAdminHandler
-Renamed as IQAdminHandlerImpl and derived from IQAdminHandler.
org.jivesoftware.wildfire.muc.spi.IQOwnerHandler
-Renamed as IQOwnerHandlerImpl and derived from IQOwnerHandler.
org.jivesoftware.wildfire.muc.spi.MUCRoomImpl
-Changed member variable from IQOwnerHandler to IQOwnerHandlerImpl.
-Changed member variable from IQAdminHandler to IQAdminHandlerImpl.
-Consturctor creates Impl versions instead.
-Updated imports.