CHcharlieegan3·Dec 16, 2020
I’m unfamiliar with the oso architecture so this might not be how it works, but I’d be interested in particular in the performance with ‘large’ input objects (~5mb+ in JSON). They have a good page in their documentation here: https://www.openpolicyagent.org/docs/latest/policy-performan... which explains the loaded data is around 20x the input - we’ve had to work around this. Though we are using OPA for something which it’s not really designed for too...
EDIT: I see this question below is answered here: https://news.ycombinator.com/item?id=25443354
Another question would be around how one extends oso. For example, OPA supports custom built-ins: https://www.openpolicyagent.org/docs/latest/extensions/. The other option is to add functionality to the language itself, e.g. https://github.com/open-policy-agent/opa/pull/2538
Oso seems to support
Read the rest
this by ‘registering’ objects in the host language, e.g. https://docs.osohq.com/using/libraries/ruby/index.html#worki... in Ruby. I like the look of this and I presume that this is how you’d rather have users build more advanced policy than extending what seems to be a pretty lightweight language (https://docs.osohq.com/using/polar-syntax.html). OPA seems to have gone the other way and has a lot of functionality in the language for common cases, e.g. x509, jwt, etc. Would I be right in assuming that the current design decision is not to add such functionality to oso?