Open jaxoncreed opened 1 year ago
Thanks a lot!.
Number 1 is PERFORMANCE:
Indeed it is priority. Note that, as storage server is io intensive than computation intensive, much of the performance story depends on how efficiently it translates resource operations to backend operations. Manas was designed to take full advantage of backend capabilities. For eg. it uses naive range request capability of backends when supported. It also reuses list metadata from object stores. Thus container rep can be computed from 1 request instead of 1 + n requests in case of fs
backend. Many such optimal usage patterns. And architecture supports to add any augmented indices as well.
- Easy configurability:
Soon multi pod provisioning, notifications, etc are landing. Then the proper config schema will be finalized. There is a plan to create an interactive config generator too.
- Authenticated searches:
Solid protocol currently doesn't standardize a query interface. TPF, QPF support provided by ESS is also global, and multi tenant. For an app i am building, this is also a consideration. I am actively exploring the space. See also: https://github.com/Telicent-io/public-rdf-abac
Lack of bugs:
Manas is written in a type driven way following Ghost of departed proofs paradigm. Thus a lot many bug possibilities are , as invalid states are made not representable in rust. Along with that rigorous test suite is in progress.
Shardability:
Yes, horizontal scalability is project's stated aim. Architecture took lot of care to made that possible. Once notifications support is landed, a proper guide, and devop helpers will be created.
It will be improving very much regularly.
Along with that, your apps can also be packaged as native apps. Tauri support will be landed this week.
Thanks for feedback.
I was asked to share some thoughts on what I would like out of Manas. Hopefully this helps.