Playground Plug-Ins: Difference between revisions
No edit summary |
(→Basics) |
||
(3 intermediate revisions by the same user not shown) | |||
Line 4: | Line 4: | ||
==Basics== | ==Basics== | ||
Logically, there will be 2 main types of plug-ins: | |||
* VSS plug-in | * VSS plug-in | ||
** Implements / overwrites a VSS Python class | ** Implements / overwrites a VSS Python class | ||
Line 12: | Line 12: | ||
*** JavaScript impl. of Google-Map like visualization | *** JavaScript impl. of Google-Map like visualization | ||
*** A set of VSS interface implementations to read the vehicle speed, acceleration, etc. | *** A set of VSS interface implementations to read the vehicle speed, acceleration, etc. | ||
* | * General plug-ins | ||
** Does not implement a specific VSS interface | ** Does not implement a specific VSS interface | ||
** Communicates with a generic cloud service (not via data broker) | ** Communicates with a generic cloud service (not via data broker) | ||
Line 25: | Line 25: | ||
Plug-ins will have meta-data | Plug-ins will have meta-data | ||
* Name, description, supported Python API | |||
* An image, e.g. used on the plug-in home page | * An image, e.g. used on the plug-in home page | ||
* An icon, e.g. used in the "Analysis" tab | * An icon, e.g. used in the "Analysis" tab | ||
* JS file | |||
* Config data for remove web services (e.g. as an editable JSon file...?) | * Config data for remove web services (e.g. as an editable JSon file...?) | ||
Latest revision as of 17:23, 17 August 2022
Plug-ins will enable external developers to extend the core playground, making sure they can implement their own use cases. The primary use for plug-ins is in the prototype runtime. This means that prototype developers can easily re-use plug-ins in their own Python code.
Basics
Logically, there will be 2 main types of plug-ins:
- VSS plug-in
- Implements / overwrites a VSS Python class
- Can also do visualization via JavaScript
- Interacts with backend via VSS data broker, if needed
- Examples: “Moving vehicle plug-in”, includes
- JavaScript impl. of Google-Map like visualization
- A set of VSS interface implementations to read the vehicle speed, acceleration, etc.
- General plug-ins
- Does not implement a specific VSS interface
- Communicates with a generic cloud service (not via data broker)
- Examples: “AI inference for Smart Wipers”
There will be 2 levels of visibility for plug-ins
- Protected
- Visible / editable for invited users
- Public
- Visible for all in the “plug-in web store”-list of plug-ins
- Editable for invited users
Plug-ins will have meta-data
- Name, description, supported Python API
- An image, e.g. used on the plug-in home page
- An icon, e.g. used in the "Analysis" tab
- JS file
- Config data for remove web services (e.g. as an editable JSon file...?)
Backend Integration
- Plug-ins can call any remote web service
- We might want to consider providing a easy way of encapsulating this, at least for standard GET functions?
- Limit to synch calls only initially OK
- Have to ensure in particular that we can contact a VSS Data Broker / Kuksa instance