@NeoTheThird Sorry, I misunderstood your words - it's not your fault - I just thought micro-services -> daemons. :)
That's something that would allow us to effectively keep control of what's running in background.
However, some of my observations are still valid; I suggest you to give a look at the "Headless apps" for BBOS10, it's worth a read.
Headless apps - BlackBerry Native
We'd need to limit CPU and memory usage for background services, a network bandwidth limitation would be desirable too. Also, services should be forced to complete their tasks within 20 seconds, in order to preserve battery life.
See Resource Management for Headless apps.
However that wouldn't solve some security concerns - we'd still need to provide a certain amount of isolation between the micro-service/headless-app and the main GUI. This would require a change in the Click package specifications, and we come back to the (infamous) question we still have to answer: Click, Snap or what else?
If there's something I like of the Maemo/Meego/SailfishOS implementation, that is its simplicity. It's pretty straightfoward to implement "local" notifications that way.
I still prefer a BBOS-like solution, but I think that we should initially focus on how to get dekko and telegram-app notifications working, understand their requirements, and then see which solution fits better.
-- About ContentHub,
I've been using it in almost all of my projects, from the DocumentViewer to InstantFX, with the authorization from the Canonical Security Team to use the "extra" permissions granted to Core Apps, or even fighting for sorting out a good user experience for an application (InstantFX) that requires a persistent access to user's Pictures folder.
There's for sure some problem with ContentHub: although it has seen an increase of its capabilities (e.g. print and clipboard support), its model has never changed since 2013. I recall that a mime type filtering (instead of those "well-known" content types) has been promised some years ago, but never landed.
I believe that user's public data (in "~/<xdg_user_directories>") should be consumed by any app or device that requires it. Otherwise there wouldn't be any need for data to be saved there, but we'd use apps private folders instead.
However I still think that ContentHub might be useful for those applications that doesn't require a persistent access to user's folder.
In any case, we might also want to change the ContentHub experience a bit:
- We may want to keep the current "peers model" for accessing private data owned by a single application. This is how it works now, and it's perfect for such scenario.
- We may want to add a file picker UI directly in the ContentHub - like in Android. That'd be useful with public data, once we have mime type support.
Canonical wanted to enhance security. That came at a cost: applications can only access to their local copy of a file.
I think the keyword here should be "privacy": applications can access user's data, but we explicitly inform the user of any change or access to her folder.
I think we should get in touch with previous ContentHub maintainer: if there's a way to change AppArmor restriction during the app executions, adding some temporary read permission, that would be great.
Generally speaking: major issues are:
- Content export: the app loses focus, therefore the user flow is interrupted.
- Content peer UI: e.g. gallery-app, it's not much usable, IMHO
- Well-known content types: not something really flexible.
Content import is annoying - that's true - and I'd like things to be handle differently. However receiving a copy of the original file is not so traumatic yet, if well handled.