...
Discussions Service: A generic micro-service that can be used to model different types of discussions. This service should expose APIs that will be used by the discussions plugin. And this service should not have an understanding of the groups or how the plugin is implemented.
Discussions Plugin: This plugin should expose a configuration that can be configured while adding to a group, have a user interface that is embeddable within groups UI and use the configuration to render the discussions for a group.
...
Discussions Service
As mentioned above, this service should be built in a generic way and expose APIs that enables different types of discussions. A few thoughts (random and not in any specific order) that need to be considered for designing the discussions service:
...
The underlying implementation can be changed from one tool to another or to a custom implementation without impacting the plugins and apps using this service.
Any customisation required to be done on top of the underlying tool (like discourse) can be implemented in the API layer.
Discussions Plugin
The main idea of plugins is to allow new functionality to be built independently of the core development. Plugins can be installed into a Sunbird instance and run as part of the core application. This enables an ecosystem of developers to develop & contribute plugins to sunbird market place (similar to wordpress marketplace). And thereby providing the agency to users to create a variety of learning experiences.
A Plugin can be composed of both server and client functionalities. Server side of a plugin can be treated as a micro-service. And on the client side, a plugin will have UI components that can be dynamically launched (with a config) by the core components (e.g groups UI component) in the client apps like portal & mobile app. Such plugins can be easily integrated and provides greater flexibility. A plugin may have only a server side component or only a client side component or both depending on the purpose for which the plugin is developed. In case of client only plugin, the plugin may use one or more of sunbird core micro-services (users, courses, etc).
Discussions plugin can be built as a client side plugin and uses APIs provided by discussions service and other services.
Configuration
Plugin configuration should provide enough options for users to configure different types of discussions within their groups. Examples of configurations are:
Allow moderated or un-moderated discussions
List of users who can play a moderator role, if moderated discussions are enabled
Enable replies on comments, enable Q&A mode, etc.
Discussions plugin will be configured differently by each group and the group component provides the group specific configuration to the plugin while launching the plugin within a group. The plugin should interpret the config to invoke the discussions service APIs appropriate for the config.
Additionally, the plugin can expose a set of configuration templates that have pre-defined configurations. This makes it easier for users to use discussions plugin by selecting a template.
UI Components
Discussions plugin should have its UI components (using Angular) which is also driven by the configuration. Different controls and actions within the UI should be enabled/disabled or act differently based on the configuration.
The UI components can be completely custom-built or embed the UI of the underlying tools (like discourse) if it is feasible, configurable (themes, actions, etc) and extensible.
Plugin Lifecycle
An important design problem for plugins is the life cycle of a plugin and the events/actions at each stage in the life cycle. We need to identify these stages and design the plugin implementation.
...
Here are some of the life cycle events for discussions plugin (not final, just as inputs for the design):
Init: when the plugin is added to a group: At this stage, plugin may need to create required entities in discussions service (like forum, groups, users, etc) and store those details as part of the plugin configuration.
Start: when the plugin is launched within a group: Plugin uses the config to fetch the relevant data from discussions service and render the UI components.
Stop: when the plugin is closed: Do any required clean up activities.
Update: when the plugin config is updated: update the related data in discussions service.
Destroy: when the group is closed or plugin is removed: clean up/archive the related data in discussions service.