-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathNOTES
58 lines (38 loc) · 3.17 KB
/
NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
/home/izelnakri/Github/rsvp.js/test/extension-test.js
- RSVP.configure('after') ??
Line 300 - assimilation etc. Check REAL A+ test suite
### Notes: Parseq research:
I really liked Douglas Crockfords parseq library, I might implement some of the Callback methods internally as parseq
equivalents in the future and expose the parseq here as well. Currenly all Callback methods are already well optimized
but exposing parseq API would be cool.
- Separation of required/optional in parseq is interesting for errors -> parseq is lower level(might need slightly more)
- Promise abstraction with timeout and retry metadata exposed publicly so I can use it inside callback.nvim
On parseq no differentiation between error and cancellation concurrency wise.
parseq.fallback fails if none returns success. parseq. fallback early returns if any succeeds -> Callback.find
time_limit works well with required_array, optional_array separation. This can be configured with time_option
-> introduces need for func wrapping as this is not intuitive but interesting and minimal.
that.each_series works means all tasks are optional, throttle is 1
parseq.race IS NOT async.race or Promise.race but it is .try_each, (it keeps going on error)
In parseq throttle 0 means infinity(keep moving), in "async" npm lib, limit 0 means skip it.
parseq.sequence is async.waterfall.
Possible new Callback methods:
Callback.all_settled
Callback.to_promise
- Async{} instance that is modelled after Promise{} instance
On _settled calls, error value is always a list with null objects(or error results)
Sanitize errors so they can be nil or null
Coming soon: `Callback.hash`, `Callback.hash_settled` APIs & Promise API/return
functionality. `_settled` waits for all tasks to settle before running result callback. These methods are different
from all other methods such that they can receive *any* values in lua, instead of just tasks, or task_operation_lists:
`all`, `all_settled`, `hash`, `hash_settles` is a higher level API than other `Callback` methods because of this.
Waiting for all tasks to settle doesnt exist right now, `all_settled` will have it with *any* value provided.
If I want to make tasks operation wait for all the settlement of *all* provided tasks, I have to use the higher-level
`Callback.all_settled` or `Callback.hash_settled` methods/API. OperationOptions type with concurrency: x, timeout: y, signal: z, onEvent, retry: a
Today `Callback.queue` and `Callback.cargo` functions are NOT implemented.
Cargo: passes array of tasks to a worker at once, could optionally repeat when the worker is finished.
CargoQueue: runs queue concurrently on workers in parallel.
Queue: passes one task at a time to a single worker.
These functions provide no persistence(for process restarts/kills) and their behavior might be achieved without needimg
them, resorting to existing methods here with a distributed store like RabbitMQ or PostgreSQL(when set up clustered).
Promise(function(resolve, reject)) -> **reject function could also be a callback shaped?**, whereas reject(nil) calls resolve and reject(false) cancelles and reject(nil, smt) resolves smt?
resolve function could be a curry of `function(val) return callback(nil, val) end`