kolibri icon indicating copy to clipboard operation
kolibri copied to clipboard

Double down on hooks, remove app plugin in favour of individual hooks for individual capabilities

Open rtibbles opened this issue 1 year ago • 2 comments

Goals

  • Separate out device integration from more specific app functionality integration
  • Allow app wrappers to initialize via configuration, rather than needing scripting to register against the previous app interface
  • Allow a single Kolibri instance to run in both 'app mode' and not 'app mode' depending on the browsing context rather than whether the app plugin is enabled - this will allow more flexible usage on Windows and Linux where there is a need to be both an app and a server.
  • Lean into Kolibri hooks for all configuration

Summary

  • Cleans up deprecated abstractproperty decorators
  • Adds a hook for adding plugins to the KolibriProcessBus
  • Adds a class property to KolibriHook to check if any hooks are registered against it
  • Deletes the app plugin and migrates all the capabilities registration to use KolibriHooks
  • Creates two device hooks for GetOSUser and CheckMeteredConnection
  • Creates a content hook for ShareFile
  • Updates capability checking to be done in individual SPAs rather than a global app capabilities utility
  • Reimplements the share file functionality that had been inadvertently removed in 0.15.x
  • Creates a new development plugin that enables all app functionality with dummy handlers, and logs the initialization URL on startup
  • Automatically runs with this plugin for development

References

Depends on #12874 to allow specifying an extra python path for the development plugin Needed to support https://github.com/learningequality/kolibri-installer-android/issues/197

Reviewer guidance

I feel like leaning into the hooks makes sense to have a single way to customize Kolibri - is there anything about this that makes this less obvious?

By separating out the specific functionality that is more 'app' versus 'device' oriented, it has made each implementation a little more bespoke - but it seems sensible to me that metered connection checking doesn't have to be exclusive to app mode - is the minor added fiddliness an issue?

With the addition of the server hooks, we could also turn ZeroConf integration into a plugin, which would allow us to turn it off slightly more elegantly - and in a swappable way so that on Android we can provide the multicast implementation via built in Android mechanisms. The other configuration that feels like could benefit from being pluggable is the restart hooks - should we push more into plugins/hooks rather than relying on options.py?

rtibbles avatar Nov 25 '24 23:11 rtibbles

Updated, rebased, and force pushed.

rtibbles avatar Dec 19 '24 21:12 rtibbles