I don’t really want to talk about dinkum here, but i can share some insight on how “classic core” became a number of independent frameworks under OpenVoiceOS, you can mix and match frameworks for different use cases as needed, our reference images bundle everything
below copy pasted from a github issue
mycroft-core → OpenVoiceOS
one common issue with mycroft-core was that you could not run a piece of the stack without importing everything else, in a server you would be forced to run the audio stack even if you are just powering a chatbot, worse, in docker setups this dragged a lot of bloat
initially we just organized imports internally to clean this up, but eventually all the pieces ended up working fully standalone and were split into their own packages
-
mycroft.api
+ mycroft.identity
+ mycroft.metrics
→ ovos-backend-client
-
mycroft.skills.mycroft_skill
→ ovos-workshop
-
mycroft.util
→ ovos-utils
-
mycroft.lock
→ ovos_utils.process_utils
-
mycroft.util.combo_lock
→ combo_lock
-
mycroft.util.parse
+ mycroft.util.format
→ lingua-franca
→ ovos-lingua-franca
-
mycroft.client.text
→ ovos-cli-client
-
mycroft.client.speech
→ ovos-listener
-
mycroft.client.enclosure
→ ovos-PHAL
+ ovos-gui
-
mycroft.audio
→ ovos-audio-plugin-ocp
+ ovos-audio
-
mycroft.messagebus.client
→ mycroft-bus-client
-
mycroft.messagebus.service
→ ovos-messagebus
-
mycroft.session
→ ovos-bus-client.session
-
mycroft.configuration
→ ovos-config
-
mycroft.tts
→ ovos-tts-plugin-XXX
+ ovos-plugin-manager
-
mycroft.stt
→ ovos-stt-plugin-XXX
+ ovos-plugin-manager
-
mycroft.audio.services
→ ovos-audio-plugin-XXX
+ ovos-plugin-manager
-
mycroft.client.speech.hotword_factory
→ ovos-ww-plugin-XXX
+ ovos-plugin-manager
-
mycroft-skills-manager
→ ovos-skills-manager
State of Things
mycroft.deprecated
as ovos-core evolved we deprecated functionality present in mycroft-core, old classes providing either dummy behavior or warning logs has been moved to mycroft.deprecated
module, this is dead code that remains in core only to avoid syntax errors in downstream projects, anything that was a public api in mycroft-core remains available in ovos-core
one of the removed things was the integration with msm which forced default skills and locked core to Mycroft marketplace
OpenVoiceOS implements a standalone skill installer utility that supports several marketplaces
mycroft-skills-manager
→ ovos-skills-manager
ovos-utils
at first ovos_utils provided generic utilities to interact with mycroft-core, over time more and more pieces from mycroft.util
moved there as they started being needed across ovos ecosystem, ovos_utils is a shared library across most of our repositories and by itself is enough to write simple scripts to interact with OpenVoiceOS
currently ovos-core mostly contains unused utils under mycroft.util
for legacy reasons, those should be fully deprecated or moved to ovos_utils
combo_lock was useful enough to become it’s own package GitHub - forslund/combo-lock
-
mycroft.util
→ ovos_utils
-
mycroft.util.combo_lock
→ combo_lock
-
mycroft.lock
→ ovos_utils.process_utils
ovos-plugin-manager
mycroft-core initially hardcoded STT/TTS/WW options, a plugin mechanism was developed but the hardcoded plugins were never migrated, OpenVoiceOS created plugins for every “native” implementation and moved all base classes and plugin loading logic to ovos-plugin-manager
-
mycroft.tts
→ ovos-tts-plugin-XXX
+ ovos-plugin-manager
-
mycroft.stt
→ ovos-stt-plugin-XXX
+ ovos-plugin-manager
-
mycroft.audio.services
→ ovos-audio-plugin-XXX
+ ovos-plugin-manager
-
mycroft.client.speech.hotword_factory
→ ovos-ww-plugin-XXX
+ ovos-plugin-manager
ovos-backend-client
as alternative backends / no backend support was added to ovos-core the mycroft.api
module ended up migrated to a more generic ovos-backend-client
, nowadays with Selene in risk of going down at any time this packages is the defacto client library for several OVOS backends, it can be used in any project to interact with several backends or directly with web apis
-
mycroft.api
+ mycroft.identity
+ mycroft.metrics
→ ovos-backend-client
ovos-workshop
ovos-workshop is where skill base classes live, it started as a way to bring bug fixes and features to mycroft-core via monkey patching, it evolved to provide skill base classes and a mechanism to develop standalone applications that interact with ovos-core
-
mycroft.skills.mycroft_skill
→ ovos-workshop
ovos-config
as configuration handling started being needed in more packages and stopped referring to a single file format or location it moved into it’s own shared library, it became the key component for XDG standards adoption and downstream voice assistant compatibility and continues to expand to this day with a cli interface recently added
once we fully move mycroft.conf from ovos-core to ovos-config it will be a truly standalone package
-
mycroft.configuration
→ ovos-config
mycroft.client
the mycroft.client
was a target for removal from core since the early mycroft days, all components there lend themselves to replacement or can be considered fully optional
the debug cli utility built on curses was moved into ovos-cli-client, this component had a totally different release cycle from core and was the only one built on top of curses, some of the code in this module was among the code not touched for longer, this indicates this is a mature optional component
the mycroft.client.enclosure
module was among the most controversial, as it directly tied to core to specific platforms recognized by MycroftOrg, it was very difficult to add platform support to core
today this module has been deprecated and the PHAL plugin framework is used across OpenVoiceOS instead
one of the things this module did was launch the ovos-gui service as part of the enclosure implementations, in OpenVoiceOS this was made it’s own service and is the source of truth for the mycroft-gui protocol implementation, it has been extended to support platform specific gui extensions
-
mycroft.client.text
→ ovos-cli-client
-
mycroft.client.enclosure
→ ovos-PHAL
+ mycroft.gui
-
mycroft.gui
→ ovos-gui
ovos-listener
the speech client was one of the pieces OpenVoiceOS improved the most, it supports multiple wake words, VAD plugins and listening modes. It is a standalone component since core can be used via text only, such as in server setups
-
mycroft.client.speech
→ mycroft.listener
-
mycroft.listener
→ ovos-listener
ovos-bus
mycroft started migrating the mycroft bus client implementation to it’s own repo, but never finished migrating mycroft-core to use it
the messagebus service is a simple websocket server, as proof of concept we developed an equivalent service in C++ to test performance, the reference python implementation is also available
-
mycroft.messagebus.service
→ ovos-messagebus
/ ovos-bus-server
(c++)
-
mycroft.messagebus.client
→ mycroft-bus-client
ovos-bus-client
a central piece of ovos-core design is that the message.context is passed along the pipeline and can contain additional metadata, this is a key feature for supporting multiple users and things such as a different language per query
ovos-bus-client is an extension (not a replacement) of mycroft-bus-client, it adds utils to interact with bus messages and it’s metadata, the mycroft.session
module has been extended and migrated to this package. this is the main design conflict between ovos-core and mycroft-dinkum, where in core the session data comes from bus messages, in dinkum this is controlled by the intent manager
-
mycroft.session
→ ovos-bus-client.session
ovos-audio
with a screen come video capabilities, the OCP framework was created to handle all kinds of playback, it uses the old mycroft audio service internally and replaces it and the mycroft common play framework
-
mycroft.audio
→ ovos-audio-plugin-ocp
+ ovos-audio
ovos-core
ovos-core is now a minimal library providing the brains of OpenVoiceOS, it is the piece that understand utterances and triggers intents, it can load skills or interface with external applications
it only depends on the messagebus which can be replaced with FakeBus for test frameworks or even with something like HiveMind. OpenVoiceOS is now several independent frameworks