...
Code Block |
---|
language | yml |
---|
title | LISA plugin configuration example |
---|
|
{
"$schema": "plugin.schema.json",
"jsonrpc":"2.0",
"info": {
"title": "Local Inventory & Storage Manager of DAC Apps (LISA) Plugin",
"class": "Lisa",
"callsign": "org.rdk.dac.lisa",
"locator": "libWPEFrameworkLisa.so",
"status": "alpha",
"autostart": true,
"description": [
"The Local Inventory & Storage Manager of DAC Apps (LISA) plugin allows authenticated downloading and management of DAC bundles from a remote server. It also manages the persistent storage of the DAC applications."
],
"version": "1.0"
},
"interface": {
"$ref": "{interfacedir}/lisa.json"
},
"configuration": {
"storages": {
"apps": "/mnt/apps",
"apps_storage": "/mnt/apps_storage",
"apps_tmp": "/mnt/apps_tmp"
},
"network": {
"timeout": 1800,
"default_retryIn": 300
}
}
} |
...
What is implemented, what NOT, development phasing
Not everything of api design has been implemented in LISA code so far. Focus has been only on Minimum Viable Product
Everything marked in italic is implemented so far, text in grey is not implemented
- Phase 1: basic API implementation and libs integration:
- initialization with basic recovery on errors (removal of all data)
- installation
- libcurl HTTP get with HTTPS and TLS session resumption
- HTTP code 202 back-off
- persistent storage creation
- untarring downloaded package
- no authentication
- no full metadata support (i.e. auxmetadata and resources)
- handling of multiple versions of the same application
- timeout is excluded
- uninstall
- operationStatus
- basic status Success/Error
- getStorageDetails
- no params (overall) Request payload: {}
- single installed application Request payload: {"type":"application/vnd.rdk-app.dac.native", "id":"<string>", "version":"<string>"}
- getList:
- no filters
- single app {"type":"application/vnd.rdk-app.dac.native", "id":"<string>", "version":"<string>"}
- getMetadata
- single app Request payload: {"type":"application/vnd.rdk-app.dac.native", "id":"<string>", "version":"<string>"}
- getProgress
- auth module API interface + stub library
- Configure logical storages on all plaforms
- Locking support (lock, unlock, getLockInfo) to prevent app from being removed while in use. LISA API Extension (Locking mechanism)
- Phase 2: whole API
- full initialization with cleanup and maintenance added (already done)
- cleanup and maintenance after each operation (already done for install and uninstall)
- installation
- full metadata
- configurable download timeout implementation
- persistent storage management (full)
- creation/deletion/reset
- quota management and enforcing (TBD how and where)
- usage reporting: per app, overall
- download (download api method : for downloading app metadata, not implemented, confusion method name by the way)
- reset
- "storage"
- "full"
- "resources"
- getStorageDetails
- single installed application Request payload: {"type":"application/vnd.rdk-app.dac.native", "id":"<string>"}
- getList
- setAuxMetada (already done)
- cancel (already done)
- Configure quotas in AS/FSM
- Review logical storages requirements
- separately for all platforms
- Phase 2: all supported platform
- review for all platforms: gaps
- Phase 3/later:
- TBD: authentication module
- TBD: apps.db - authentication, antirollback, encryption
- TBD: concurrent parallel downloads
- TBD : Max quota per specific app? Not sure what is use case/expected behaviour config here
...