There are design questions about how to tackle permissions. I want to expose "service" layer which checks permissions more alike what a user of an S3-like system would expect. Currently, the only permissions are handled by BonsaiDb directly, but that does not allow building permission rules unless you know the file's ID -- very cumbersome.
This service layer would take a privileged connection to run its "backend". This type could be used on the server implementation, and would support Api types for network access.
There would need to be a duplicate API surface that allows reading/writing files from this service layer instead of directly from collections. I'm sure this can be simplified nicely behind the scenes with traits.
The other two ideas I had don't deserve as much explanation:
For the buffered reader, would a version that always requests the next chunk from the database in a separate thread/task be helpful? I think it needs benchmarks, and the design was complex enough I just tabled the idea.
A way to "tail" a file would be awesome -- PubSub events for appending to a file, and a way to "update" a Contents with new blocks.
There are design questions about how to tackle permissions. I want to expose "service" layer which checks permissions more alike what a user of an S3-like system would expect. Currently, the only permissions are handled by BonsaiDb directly, but that does not allow building permission rules unless you know the file's ID -- very cumbersome.
This service layer would take a privileged connection to run its "backend". This type could be used on the server implementation, and would support Api types for network access.
There would need to be a duplicate API surface that allows reading/writing files from this service layer instead of directly from collections. I'm sure this can be simplified nicely behind the scenes with traits.
The other two ideas I had don't deserve as much explanation:
Refs #222