Cleanup API

[Clément Delafargue]

Some old parts of the API are still there and might not be useful anymore (they mix somewhat arbitrary high-level datalog idioms with library-level code).

I think they can be safely removed, or at least put in a separate module.

// in BlockBuilder
pub fn check_resource // imo this should be removed altogether
pub fn check_operation // imo this should be removed altogether
pub fn resource_prefix  // this should at least moved to a dedicated module, or removed
pub fn resource_suffix   // this should be at least moved to a dedicated model, or removed
pub fn expiration_date  // this could be moved to a dedicated module, rewritten using a datalog string, with the variable renamed to `$time` to use the default symbol table

// In Authorizer
pub fn allow // this should be moved to a dedicated module (and maybe renamed to `allow_all`)
pub fn deny // this should be moved to a dedicated module (and maybe renamed to `deny_all`)

// In Biscuit
pub fn create_block // this just calls `BlockBuilder::new()`. i think it's a bit misleading to have it a method on `Biscuit`, since
                    // it seems to imply that the builder is somehow linked to the biscuit when it isn't. 

One of the goals of datalog is to use common logic across languages, so i see using language-specific helpers as a bit of an anti-pattern, i'd rather have easy-to-read datalog than ad-hoc helpers. Parameter substitution solves the issue of injecting dynamic values, and compile-time parsing will solve the perf issue of using datalog-as-strings.

We should also provide a way to combine BlockBuilders: since the macro feature generates block builders from datalog code, it would be convenient when needing to create facts by iterating over vecs for instnace, while keeping a consistent high-level api.

[meh.]

Unless I'm using allow wrong, isn't that supposed to be like "allow anything if all the checks pass"?

In that case I like allow and deny the way they are because I use them as the last statement in my builder helper thingy.

[Clément Delafargue]

I think allow_all would make it a bit clearer that it's a catch-all

[Clément Delafargue]

i guess my point is: i think we should favor using the datalog syntax as much as possible over the builder syntax, so imo, authorizer!("allow if true"); would be better than allow().

[Clément Delafargue]

the helpers are still there, but in a separate extension module