Page Comparison

...

The framework should provide an SDK which exposes the basic services that will be used by the plugin

...

is conceived it is related to a specific task which is to be accomplished. The reason for someone thinking of creating a plugin is that this task cannot be accomplished using the core parts of Sunbird. The need to accomplish the same task (or a minor variant) may not be unique to the person or group who thinks up the plugin.

Thus a repository of plugins with screenshots, descriptions and license terms can be instrumental in making plugins re-useable and discoverable by the community.

Providing a template for adding screenshots and descriptions will standardise the method in which templates are published

Providing a means for rating and giving feedback on plugins will create sense of security and confidence when installing the plugin.

Collectively, this can form the foundation of an app store for Sunbird plugins. (see Envato marketplace for WordPress plugins)

Implementation Design

To design the implementation of a plugin, the plugin author will need access to a specification of extension points, one or more examples demonstrating the scope of extensibility and a specification of Sunbird core APIs available for creating a plugin

UI Design (web/mobile)

To Load the Plugin.

Prerequisite from Framework

The framework should provide hooks so that the plugin can load its UI in the required position.

The framework should expose placeholders on the UI in different places like Homepage, Profile page, course page etc

The framework should provide a mechanism to load the file's of the plugin like Js, CSS, and any other asset

Data access from UI

Prerequisite form Framework

The framework should expose some of the services that plugin can access like,

1. HTTP service
2. logger service
3. Auth service
4. Eventbus service
5. listner service

the plugin should be able to get the data like who is the current logged in user and the currently active session details so as to use this to call the API to get the required data to the plugin.

JS will decorate the DOM

once the data is available from the service to the plugin, plugin JS will use this data to decorate the DOM and will use two-way data binding.

User Interaction with the pages

Once the DOM is created and updated with data now it will wait for user interaction or any event that is listened by the plugin.

Respond to the event

the framework will provide event handling and broadcasting mechanism that a plugin can use to call other plugins or to broadcast its event. the plugin must register to these events and handle accordingly.

the plugin can also emit events so that any dependant plugin can do a callback on that

Data Update from UI

once the user interaction is handled and all the data processing is done the data need to be persisted. plugin calls the services to do this process.

For plugins(web/server/mobile)

...

When designing the UI for a potential plugin which has web/mobile views the plugin author can be faced by a few different scenarios

Adding elements to an existing UI view
Creating a new UI view
Providing an alternate implementation of an existing UI view

Adding elements

To add elements to an existing view,

a declarative language and format is needed which can allow a plugin to declare elements for existing pages
to accomplish this the framework should provide a vocabulary of pages which can be extended
To simplify initial scope, there can be a fixed vocabulary of view sections (like header, footer, menu, navbar, search filters and others) where new elements can be added
The implementation may be interrogative where the framework interrogates the plugin for elements or could be registration based where the plugin registers elements with the framework. The latter provides easier debuggability

New views

Creating new views depends on adding elements to existing views to create navigation entry point for the new view
Creating a new view will also require the ability to add common elements and behaviours from other parts of the web app or the mobile app

Alternate implementations

To provide an alternate implementation of a view,

the declarative language and format which allows a plugin to provide elements for existing pages can be extended for a plugin to provide implementations for pages
to accomplish this the framework should publish a vocabulary of pages which can be replaced

UI Consistency

to ensure that the plugin UI is consistent with the rest of the application, the framework will need to publish styles which can be applied inside the plugin UI
the framework will also need to inject additional assets (CSS/JS/media) created by the plugin into views where the plugin is loaded

Implementation (Code)

To provide backwards compatibility with framework upgrades, the framework must provide SDKs which exposes basic services used by the plugin. The SDK implementations will provide interface compatibility with framework. Separate SDKs may be required for Web, Server and Mobile plugins

Server SDK

API Management

Declare an API
Declare permissions for an API
Provision an API into the gateway

Storage Management

Create a new table
Store data into a table
Index stored data into a secondary index
Retrieve data by PK
Retrieve data by SK
Search for data
Delete data in the table
Upgrade schema
Delete tables

Sunbird

Access Sunbird services
- Authentication: to get data for the current logged in user and session
- Logging: to add log records for debugging
- Telemetry

Others

Secrets: to register/retrieve/delete secrets which can be retrieved at runtime (eg: an API key for a 3rd party service)
HTTP: to make 3rd party API calls
Queue: Enqueue an asynchronous task, schedule a task for later

Web SDK

HTTP service
Auth service
Token service: to get a token to call a sunbird backend API
Secrets service
EventBus Service: to dispatch and listen for events and allow for inter-plugin communication

Mobile SDK

Permissions

Request for permission
Check for permission

Testing

The framework will provide the basic testing env required by any plugin to test the Integration of the plugin with the framework

...

automated integration testing.

Debugging

Debugging will be a strong need of any plugin development. The framework should ensure that loaded plugins can have debuggers attached within the plugin. This means that the plugin code must be reference-able from the standard debugger.

Each plugin should use an effe74ctive logging system which will provide all the logs in a central place. To accomplish this, the framework will expose logging mechanism that each plugin can extend and use to log. This will help in debugging process.

Publishing

A standard process to build and publish the plugin will be exposed by the framework so that all plugin will follow the same process. The publishing process must allow for a plugin to create its own dependencies.

Integration/Deployment
The plugin will specify what is the purpose of the plugin and who all can use it like web/server/mobile. Depending on the use and need for the plugin the Adopter of the framework will use the plugin and integrate it with the endpoints.

Debugging
Debugging will be a key feature of any plugin. so each plugin should use an effective logging system which will provide all the logs in a central place.

in association with this, the framework will expose logging mechanism that each plugin can extend and use to log. this will help in debugging process.

Version Control

Plugins will be version controls this will help in keeping the history of the plugin and helps collaborate on the plugin with other developers

...

Versioning

Plugins will be versioned to help in keeping the history of the plugin and helps collaboration between plugin developers.

Installation

The framework must provide a means for plugin to be installed into the application.

Web plugins

Web plugins will be installed at build-time by incorporating the plugin source code into the portal source tree and rebuilding the portal client application. The installation will require updating the root app.js code to import the appropriate plugin modules into the root of the application.

Server plugins

Server plugins can be installed as NPM modules or by incorporating the plugin source code into the backend application source tree and rebuilding the portal server application

Mobile plugins

Mobile will be installed at run-time by the mobile app downloading the the plugin source code from the backend into the mobile app as a hot-code deployment.

Activation/Loading

Runtime: UI based plugin (web/mobile)

Data access from UI

During this phase, the plugin uses the basic services provided by the UI framework to load data from one or more backend APIs

JS decorate the DOM

Once the data is available from the service to the plugin, plugin JS will use this data to decorate the DOM and will use two-way data binding.

User interaction with views

Once the DOM is created and updated with data now it will wait for user interaction or any event that is listened by the plugin.

Respond to interaction or event

The framework will provide event handling and broadcasting mechanism that a plugin can use to call other plugins or to broadcast its event. The plugin must register to these events and handle accordingly
The plugin can also emit events so that any dependant plugin can do a callback on that

Data Update from UI

Once the user interaction is handled and all the data processing is done, the data needs to be persisted. The plugin calls one or more services to do this process.

Runtime: Server Plugins

Runtime: Mobile Plugins

Deactivation/Unloading

Upgrade

If the extensibility framework is updated then it should be backwards compatible to ensure plugins are not broken. There will be a times where the framework upgrade is backwards incompatible. In these situations, an alert has to be sent to the plugin contributor so that the developer can plan for a plugin upgrade. The framework upgrade should provide for a deprecation period where a framework API is deprecated giving plugin authors time to upgrade their plugins.

Upgrade-Alert

...