blob: c922d5df88e1b1dd2204063dc11e51f783aa7903 (
plain)
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
|
refactors
- fatcatd -> fatcat-api-server
- fatcat_api -> fatcat_api_schema (or spec? models? types?)
- standardize "mutating"/"edit" actions
=> have editgroup_id be a request-level param everywhere (not entity-level;
for batch)
=> editgroup_id as query param
=> editor_id from auth (header)
- consistent "expand"/"stub" flags
correctness
- enforce "previous_rev" required in updates
- reread/review editgroup accept code
- enforce "no editing if editgroup accepted" behavior
- changelog sequence without gaps
- batch insert editgroup behavior; always a new editgroup?
edit lifecycle
- editgroup: state to track review status?
- per-edit extra JSON
account helper tool
- set admin bit
- create editors
- create keypairs
- generate tokens
- test/validate tokens
later:
- pure-rust "benchmark" scripts that hit, eg, lookups and batch endpoints
=> criterion.rs benchmarking
- try new actix/openapi3 codegen branch
- refactor logging; use slog
- test using hash indexes for some UUID column indexes, or at least sha1 and
other hashes (abstracts, file lookups)
schema/api questions:
- url table (for files)
- get works/releases by creator
- "types"
- define release field stuff
- what should entity POST return? include both the entity and the edit?
|
