Feature/client manage multi addresses: Part 1 #428
Conversation
…b.com/MystenLabs/fastnft into feature/client-manage-multi-addresses
…b.com/MystenLabs/fastnft into feature/client-manage-multi-addresses
oxade
requested review from
huitseeker,
lxfind,
patrickkuo,
sblackshear,
gdanezis,
kchalkias and
arun-koshy
|
Please excuse all the commits. Workspace got screwed up. Will squash on merge. |
| /// ------ SingleAddressStore3 | ||
| /// | | ||
| /// ------ SingleAddressStore4 | ||
| pub struct ClientAddressManagerStore { |
There was a problem hiding this comment.
A common practice I see from other blockchains is that there is a simple rule to name the store for each address. For example, each address's path is named as the public key of that address.
That way, you don't really need the ClientAddressManagerStore.
There was a problem hiding this comment.
But I could be wrong. Maybe someone who is more familiar with blockchain client local store can comment. @huitseeker @sblackshear
There was a problem hiding this comment.
I can change it but does this matter much? It's not exposed to the user.
ClientAddressManagerStore is simple now but the plan is to in future do fancy stuff like shared immutable object archive across all addresses to reduce storage footprint and time spent fetching etc.
|
@patrickkuo will address the comments, thanks |
* Expose primary handles * Expose workers handles
* Expose primary handles * Expose workers handles
This allows one
Clientto manage multiple addresses as shown in diagram from this issue: #275Part 2:
Allow multithreaded instantiations
Improve naming of components
Addresses share the same archive store (?)