pushing to /v1/client always updates the associated data for the given
endpoint. under this design, it is up the endpoint to decide if they
want to maintain their data (by including it in the POST) or if they
want to erase any associated data (sending a POST with a zero payload).
this approach is based on what i've experimentally figured out in
https://git.coopcloud.tech/decentral1se/iroh-go/src/branch/main/examples/http-dialer
(thus the large diff X)
this is still wip but the basics work! this approach is more pragmatic
than previously. it allows clients to send http queries over iroh to a
simple http server, instead of needing to implement a so-so
wire-protocol.
refactor Stack to "store an interface" i.e. items []Keyer -> interface Keyer { Key() string }
if storing []Keyer instead, i can store a struct that can contain any number of other fields.
this stack implementation has a fixed-size. new items are pushed to the
front and, if the capacity has been met, the last item gets evicted. if
you push an item onto the stack that was already on the stack, this
"bumps" that item by merely moves the item to the front (as opposed to
allowing duplicates). the capacity is set at initialization.
the intended use case for this data structure is for the iroh-tracker to
only keep a fixed amount of topics and, per topic, a fixed amount of
peers. topics that are actively recalled get pushed to the front, and
peers within a topic that are seen often also get pushed to the front.
see examples/stack-example.go for how it can be used
eventually i'll refactor this to use just bytes instead as that is more
useful for the purpose of the tracker. this could also be an opportunity
to look into generics since string & byte are basically interchangeable.
TODO:
* decide on future response structure but maybe prefixing with the name is ok
* decide on error/nil values
* server: actually do things with the data sent to us by client
cblgh