Disclaimer: I'm not PLIP'n anything nor have implemented much yet.
We have discussed about the possibility of "through-the-web" (TTW) installable add-ons for years. Talk, a lot. Results, not so much. But in practice, for the last years, at least I've deployed TTW supported features bundled with themes for all of our new Plone 5 based sites (with the help of collective.themesitesetup and collective.themefragments): content types, restricted templates, frontend resources, custom localizations, workflows, permissions, content rules and, obviously, a lot of configuration. For the most, I've just used the currently existing features in Plone, mostly GenericSetup and RestrictedPython.
How unique feature of Plone is that thanks to Zope 2 legacy, we can deploy more features securely through the browser? (Yes, Wordpress has supported TTW upgrades for ages, but only by allowing it to rewrite its own code.) If so, why are we so shy of that? Or is there known security limitation in RestrictedPython, which we all should be better aware of?
Sure our TTW approach does not support everything. There are very strict limitations, which are support by either GenericSetup or RestrictedSupport. And especially with RestrictedPython the limitations often surprising (resulting hard to understand and debug unauthorized errors). Adding new features for GenericSetup is doable, RestrictedPython is more tricky. This is probably also the reason, why we still don't have official TTW add-on story: we have been afraid of the confusing of TTW development, hard to understand differences between TTW and filesystem add-on, and have been unable to decide, which features should be supported by TTW add-ons.
Since we've been unable figure out "the right way", I suggest, that we should just accept the current status quo and two tiers of add-on development and embrace it:
- eggs, file system add-ons are trusted and can do anything
- TTW uploadable "apps" remain untrusted and can only build on top of the features provided by file system add-ons (e.g. use behaviors, content-rules, portlets, tiles, etc defined in those) within limits of RestrictedPython
The confusing differences between file system and TTW development would remain, but the benefits of good TTW story should be big enough that users would just learn and accept it.
Personally, I'm interested in developing framework and UI for TTW add-ons, possibly by hijacking collective.ttw initiative, but only within the scope of features supported by the current Plone backend (e.g. I would not like to support z3c.jbot, because as seen in collective.jbot, that requires breaking out from RestrictedPython sandbox):
- manifest format for "apps" (deps, versions, update address, signature, etc... features similar to old Firefox add-ons)
- configuration panel for installing, updating apps, disabling, enabling and uninstalling apps (but note that in practice, "clean uninstall" would really depend on add-on and would be really hard to enforce)
- apps would be separate from theme and managed under custom plone.resource namespace
- apps could also be developed TTW using filemanager-pattern based UI (it's getting pretty cool after GSOC by @b4oshany)
But now it's the time for "stop energy". Why this should not be done? Am I missing something obvious? Is the two-tier add-on story more threat than possibility? Are there issues in RestrictedPython security, which makes this not worth of effort (as in why not just allow uploading wheels, write to filesystem and restart instance)?