Update bsip-0040.md

bsip53
Stefan Schießl 2018-07-28 23:43:28 +02:00 committed by GitHub
parent bcfa32f90c
commit 5da66a4c34
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 8 deletions

View File

@ -82,9 +82,9 @@ List of possible asserts are:
| `length` | [`min`, `max`] | stateless |
| `limit` | [`max_cumsum`, `interval_in_sec`] | [`current_cumsum`, `interval_began`] |
| `limit_monthly` | [`max_cumsum`, `interval_in_months`] | [`current_cumsum`, `interval_began`] |
| `contains` | [`list`, `of`, `allowed`, `fields`] | stateless |
| `contains_only` | [`list`, `of`, `allowed`, `fields`] | stateless |
All asserts apply to `int`, `string` and `object_ids`. There is no type converstion, incompatible type means assert failure. Any more sophisticated data types are not included yet.
There is no implicit type conversion when attempting to assert, incompatible type means assert failure.
In the following we list possible `asserts`. Mentioning `argument value` refers to the value of the argument of the operation specified `argument` in `assert_object`.
@ -96,10 +96,10 @@ Stateless assert, all argument types. `Argument value` must NOT be equal to any
#### `lt, le, gt, ge`
Stateless assert, only `int` type arguments.
- `lt`: `Argument value` must be less than `comparitive`
- `lt`: `Argument value` must be less than or equal to `comparitive`
- `lt`: `Argument value` must be greater than `comparitive`
- `lt`: `Argument value` must be greater than or equal to `comparitive`
- `lt`: `Argument value` must be less than `comparative`
- `le`: `Argument value` must be less than or equal to `comparative`
- `gt`: `Argument value` must be greater than `comparative`
- `ge`: `Argument value` must be greater than or equal to `comparative`
#### `length`
Stateless assert, only `string` type arguments. Length of string (or encrypted string in case of memo) must be within `min` and `max`, inclusive. One of the bounds can be empty to indicate unlimited.
@ -163,8 +163,8 @@ Notes: The implementation must not differentiate on which operation the custom a
# Milestones
We propose do split the implmentation into two milestones:
1. Implementation of basic functionaliy to allow custom active permissions and authorities, including `range`, `length` and `any` `asserts`
2. Evaluation of stateful asserts (performance) and if positive, implementation of `limit` and `limit_monthly` `asserts`
1. Implementation of basic functionaliy to allow custom active permissions and authorities, including `any`, `none`, `lt, le, gt, ge` and `length` `asserts`
2. Evaluation of stateful and more sophisticated asserts in terms of performance and if positive, implementation of `limit`, `limit_monthly` and `contains_only` `asserts`
This approach allows as well to add other asserts at a later stage (with a new BSIP).