Further features for the room owner plugin
Changes required to how core endroid interacts with the room owner plugin to support the following featurettes:
* Provide a cleaner separation between core endroid and room owner config
* Support EnDroid joining rooms (with passwords) without 'owning' them
* Minimise the number of times a room name must be specified in the config file
* Support XMPP servers using different MUC config item names
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Medium
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Config proposal:
# Rooms EnDroid should join with optional password specified
rooms = <email address hidden>
@@@MM: fortunately, colon is one of the few unsupported chars in a JID, so this works. :-) http://
# Rooms EnDroid should own
[ room : <email address hidden>: plugin : roomowner ]
users = dave, phil
password = guest
name = "EnDroid's room"
description = "A room"
Pro: is quite succinct, Con: means the section headers become config themselves.
Initialisation:
On startup endroid should start a global roomowner (RO) plugin (requires global plugin support) alongside joining any rooms as per its config.
The global RO plugin then performs the following for each room it should own:
* Find out if EnDroid is the owner of the room - error if not
* Get current room config, mark and sweep against configured (+default)
* Get current memberlist and mark and sweep against configured (+default)
* Tell Endroid to join the room (with password if needed) - triggering EnDroid to instantiate room specific plugins
Implementation notes:
* Room roster class shouldn't track member_list - that information is only held by roomowner and besides it is not known for rooms EnDroid doesn't own.
* Invite plugin therefore needs to interface with roomowner and not core endroid (relevant APIs need to be created).
MUC server types:
On receiving the config for a MUC. EnDroid knows the config items supported for the MUC server.
Either explicitly (via config) or implicitly (via result from the getConfig) EnDroid should determine whether this MUC server is supported and instantiate the appropriate class (encapsulating config mappings amongst other things) to handle the room.
Questions:
* Which config model to go for (see above)?
* How to specify MUC server type (or have it implicit)?
