commit c403cce27d359266f8f3d8570512d115a217265e parent fcca85c7c6e44bb6009c452e85e818c054353d7a Author: Martin Schanzenbach <schanzen@gnunet.org> Date: Tue, 22 Feb 2022 19:56:27 +0100 add todos Diffstat:
| M | draft-schanzen-r5n.xml | | | 26 | +++++++++++++++++++++++++- |
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml @@ -1358,7 +1358,7 @@ Connectivity | |Underlay| |Underlay| </section> </section> <section anchor="blockstorage" numbered="true" toc="default"> - <name>Block Storage</name> + <name>Storage</name> <section> <name>Block Processing</name> <t> @@ -1587,6 +1587,30 @@ gnunet+tcp://12.3.4.5/ \ </figure> </section> </section> + <section> + <name>Storage API</name> + <!-- + FIXME TODO + We need exact store, lookup and APPROXIMATE + - Approximate: look for X blocks with key > lookupKey and key > lookupKey + each and then order by XOR distance. Return X results. + - AFTER that we filter through block plugin (may discard bc of xquery) + - Implementation should decide if further results required based on + resources / storage size. + --> + </section> + <section> + <name>Caching Strategy</name> + <!-- + FIXME TODO + What should an implementation consider when managing the + cached blocks? + - Number of served requests for the block (MAY, can be expensive) + - Proximity my peer ID (MAY) + - Configurable quotas / local storage size (SHOULD) + - Block expiration (this is what we do atm) (MUST) + --> + </section> </section> <section anchor="security" numbered="true" toc="default"> <name>Security Considerations</name>