Plone currently has two very different security contexts: one trusted (without internal security checks because the security has been applied further upwards towards the user/request) and one "untrusted" (with explicit checks for each operation). One consequence thereof are the two sets of catalog methods ("normal" and "trusted").
With respect to this, one should ask what of these security contexts is targeted by plone.api and its functions. A function destined for the trusted context may be a risk in the untrusted context. Like for the catalog, it may be necessary to have two versions of a function - one for the trusted and one for the untrusted context.
It's really too hard to give something meaning unless you are really lucky or influential.
We are better to have something that is descriptive but still sounds smooth (otherwise it won't be used).
Apps is too overused and I think its a different idea from something that adds a feature. An app is generally an destination in itself.
I think the ideas are around "X add-on" which is saying its very similar to other kinds of addons that add features or modifications to the CMS but without a restart or redeployment. So hotswap addons or live addons. Or going forward you can forsee a install process where you pick it from some webstore and click install and its done.
So maybe just "web addons"?
I'm pretty sure that plone.api was designed and developed primarily the trusted context in mind. It's only used in TTW context by default in Rapido. Rapido's restricted Python scripts are different from default Plone "untrusted" Python scripts in that it does not use guarded getattr with RestrictedPython. In my understanding that is for convenience, because guarded getattr prevents access e.g. to Python datetime objects' functions (Zope DateTime has explicit support for AccessControl).
That said, I obviously want the TTW add-on story to fully work in "untrusted" context by default, but make it extensible so that Rapido could later support it.
No it used untrustedpython because it seemed that it would be more supported in the future and because it also works on pyramid. @ebrehault is now switch it back to using pythonscripts version of restrictedpython since this now seems like it will be supported into the future.
It was never about lowering the security.
It's a really bad idea to try and tell people they have to use two apis. If plone.api doesn't target untrusted users and the solution is to have multiple apis then we have created yet another obstacle to adoption. Is there any reason why plone.api can't be made to transparently be supported in untrusted code?
I agree, X add-on seems to be the safes bet. I liked also mods, but as @tmassman surveyed, it's probably too technical. apps might be oversell (although, it's also beyond meaningless).
So, how about "Instant add-ons". That should be both positive and describe their function pretty well. And like instant coffee works best with freshly boiled water, also "Instant add-ons" are best served with freshly installed Plone. (Of course, they work on any Plone, but are allowed to override settings.)
When only positive votes are counted, apps remains high. This is tough.
Ok, but makes naming even harder
Then I have missed something. How to invalidate specific key on plone.memoize.ram? I know only that the key can be changed, but memory is released only when RAM cache is full or maybe clears unused keys.
Apps would each be stored in its own plone.resource directory (under apps namespace).
Public would be visible for anon users through custom traversal adapter, similarly to ++theme++, but eg. ++app++. All the rest would remain private (new plone.resource is directory namespaces are not automatically published).
Resources would be to populate other resource directory namespaces: theme, sitelayout, contentlayout, ... I'd like to support using namespace per purpose instead of bloating one like currently with theme.
How to better distinct those?
Also, I have mixed viewish templates and tiles in themefragments and it probably confused more than helped. Also, I'd like this to be usable also without Mosaic.
Don't use that as any indication. Other than the fact we aren't the target audience, and design by committee almost always picks badly, participation in a thread like this isn't even well balanced vote.
You really have to try out the names, particularly with the target users and see what sticks. It's also useful to start writing the documentation.
An initial approach could be to give the API functions security declarations mirroring those of the underlying operations. However, Zope's security system is object oriented: you may have rights locally at an object (and not globally). When I remember right, may API functions are not methods but get the object they operate on as a parameter - then the automatic security checks cannot take into account local rights at the object and the checks must be made explicitly in the code - leading to the potential of security holes.
Then perhaps we need to scrap plone.api and start again. Any system with 2 apis for the same thing is confusing as hell. Plone.api was meant as a replacement to make documentation easier. Seems like it wasn't designed as a full replacement.
To give more context... The way I think is that our goal is to make plone more popular. To drive adoption. Not just to make it nicer for the existing developers. Instant addons are a great way to do that. Making the documentation and apis for instant addons be as close as possible to filesystem addons is a great way to do that. To avoid support requests like "I'm trying to use this api in my addon and it's not working", "What kind of addon is it?". All that tilts the fun-o-meter towards zero.
It's worth going the extra mile to make things consistent and easy to learn is all I'm saying. So you can recommend plone to kid brother or sister.
Should I call resources as populate instead? But that would sound like populating site with content, not populating plone.resource directories. Naming is hard. Some of my folders are verbs, some are nouns... The original resources came from plone.recipe.zope2instance's default option for a filesystem mount for plone.resource.
Luckily most of (if not all) plone.api methods eventually use those old methods, which have security declarations. So, for many use cases plone.api actually seems to work properly also when exposed TTW.
But the issue is that because plone.api has not been developed or automatically tested in TTW use case in mind, it should not be considered safe_module by default yet. Eric knows about the current issues with Rapido, so I don't go into those in detail here. After all, Rapido scripts are usually only by the site administrators, who own/pay their servers.
That said, fixing plone.api to work safely TTW is beyond the scope of this thread. I will only care about the API available in possible Python scripts, when it's possible to easily share workflows, content types, simple templates and other TTW configurable features between sites in a reusable and maintainable way.
Why don't we just start a public survey (e.g. on plone.org) and ask our users/customers what they prefer?
Also, I think it is ok to name it like "ttw addons" internally (the technical term, so we can start coding something), and the front-end labels/naming will be adjusted once the survey is evaluated.
plone.api was designed for having oneliner shorthands for common developer patterns. It was also supposed to be called plone.ipa as it's almost an inverse of an API in some regards. It was put together during the Belgian Beer Sprint, which might also have been an influence in the naming debate.
Security declarations are ineffective when used from "unrestricted code". What makes them effective is the replacement of getattr by guarded_getattr in "restricted Python". The latter looks for security declarations and verifies them.
This may hint toward a solution: we could have two implementations of plone.api -- i.e. the same API but differently implemented; one implementation for use by "unrestricted code" and one for use be restricted code. It might be that for the latter is could be sufficient to peephole the "normal" implementation by replacing "getattr" by "guarded_getattr".
Considering all the feedback, I'm planning to start development of control panel and documentation of packaging under package name plone.app.addons and call them Instant Add-ons for now. I agree that it could be branded better if all this works out.
I'll start with packaging and control panel and priories GS support before the rest. I expect to have something before the conf.
+1, I'm aligned with this idea, making it easier to use, easier to extend and easier to explain is a good thing. The challenge is doing that while navigating the realities of security, dealing with breaking changes, etc...
I like the term "instant add-ons". It is more descriptive than some of the other names.
I'd love the name to communicate:
Easy to Build in the browser
Easy to install
Quick
Safe
Adds new capabilities
"instant add-ons" covers 2, 3 and 5 (maybe it also hints at 1).
