Shell UI is to represent the user interface includes light and audio effects.
Voice UI is to handle all voice-based user interface requests.
Display UI is to handle the requests to render for products with screen(s).
The basic services are:
MediaPlayerDaemon is a service that controls all the media tasks.
TextToSpeechDaemon is to control all the TTS requests.
BluetoothService is the service that manages all the bluetooth tasks and states, also the abstract layer for different low-level implementations like: bsa_server or bluez.
Activation is to optimize the awaken user experience, but only controls the sound.
PulseAudio is still awesome software that we should use more to manage the sounds.
The above are just naming optimization than our current implementation, not big addresses and improvements.
Redefinition of YodaRT
We have to refine the meaning of YodaOS Runtime, namely YodaRT. In our implementation, this runtime includes all basic services implementations and libraries, which might be not clear for any incoming developers.
Thus, as the first step of starting the next parts, I propose that this runtime includes the following:
The base libraries which abstracts the functions that the framework layer would use, we call it “yoda library”.
The core UI components source code, that includes: shell, voice and display.
So the new root directory would only contains: lib, shell, voice and display.
Yoda Flow
Except for the shell, voice and display components, we should have a component named as “flow”, which is the tiny core to provide the minimum support for all the use cases.
The Flow should own the following abilities that we resolved in v7:
Apps loader.
Apps scheduler.
Custodian for network manager.
Dbus expose.
Keyboard controls.
Lifetime of applications and skills.
Permission controls.
MQTT wormhole.
To be continue, but any ideas is also welcome to chime in :)
Now we have the following UIs to work with:
The basic services are:
MediaPlayerDaemon
is a service that controls all the media tasks.TextToSpeechDaemon
is to control all the TTS requests.BluetoothService
is the service that manages all the bluetooth tasks and states, also the abstract layer for different low-level implementations like: bsa_server or bluez.Activation
is to optimize the awaken user experience, but only controls the sound.PulseAudio
is still awesome software that we should use more to manage the sounds.The above are just naming optimization than our current implementation, not big addresses and improvements.
Redefinition of YodaRT
We have to refine the meaning of YodaOS Runtime, namely YodaRT. In our implementation, this runtime includes all basic services implementations and libraries, which might be not clear for any incoming developers.
Thus, as the first step of starting the next parts, I propose that this runtime includes the following:
So the new root directory would only contains: lib, shell, voice and display.
Yoda Flow
Except for the shell, voice and display components, we should have a component named as “flow”, which is the tiny core to provide the minimum support for all the use cases.
The Flow should own the following abilities that we resolved in v7:
/cc @Rokid/nodejs