In general, you shouldn't really need to pass in large input objects to oso - it operates over the application data.
What this means practically is either the data is processed through whatever data access layer you have (i.e. SQL, or an ORM). And there's more work we're doing here to make that experience seamless [1].
Or if you do have some large input data and you iterate over it in the policy, then the oso host library (the part in your app) will just iterate through it without sending the entire object back and forth.
> 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
Yep, that's the idea. I answered a similar question here [2]. You can call class + instance methods from Polar, so if there's anything you can't do you can add it that way. We have considered/are considering adding a standard library to provide common pieces out of the box, but it's not a limiting factor for using oso currently.
There are some side benefits though that a standard library would provide - like having a robust implementation of common operations in the Rust core.
Thanks for the prompt & detailed responses in this thread.
It’ll be interesting to see what this looks like in a polyglot stack, I think that’s where having functionality in in the policy language might be really valuable.
For the time being, it’d still be possible to build a oso based policy server which applications invoke to make consistent decisions - so there are options to achieve this in the meantime too.
Agreed! And I strongly recommend to anyone thinking about doing so to join our slack [1] and come chat with us :) We'll be happy to share our thoughts on this.
All these questions are also tempting me to go and put together a demo for this too...
What this means practically is either the data is processed through whatever data access layer you have (i.e. SQL, or an ORM). And there's more work we're doing here to make that experience seamless [1].
Or if you do have some large input data and you iterate over it in the policy, then the oso host library (the part in your app) will just iterate through it without sending the entire object back and forth.
> 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
Yep, that's the idea. I answered a similar question here [2]. You can call class + instance methods from Polar, so if there's anything you can't do you can add it that way. We have considered/are considering adding a standard library to provide common pieces out of the box, but it's not a limiting factor for using oso currently.
There are some side benefits though that a standard library would provide - like having a robust implementation of common operations in the Rust core.
[1]: https://docs.osohq.com/getting-started/list-filtering/index....
[2]: https://news.ycombinator.com/item?id=25443354