You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of now, Multiaddr stores a byte array, representing the serialized version of the address.
Although this allows very fast serialization (array copy), I believe this is not the most appropriate format.
Indeed, operations on Multiaddr (eg. decapsulate) actually work on the list of protocols, and not on the byte representation. The bug mentioned in PR #18 is a good example of it.
I see two possible representations:
Make Multiaddr store a Vec<Addr>, with Addr being an Enum for all supported protocols
Make Multiaddr only store an Addr and an Option<Multiaddr> for the inner and/or outer multiaddr.
The text was updated successfully, but these errors were encountered:
So my goal with how it is currently stored was to have internally the same byte representation as go-multiaddr has. If we move away from that, there needs to be at least an option to get that byte representation via a method call.
From your suggestions I think I like using Vec<Addr> the best as that matches my mental representation of a multiaddr very well. What do you think?
ntninja
added a commit
to ntninja/rust-multiaddr
that referenced
this issue
Oct 25, 2017
As of now, Multiaddr stores a byte array, representing the serialized version of the address.
Although this allows very fast serialization (array copy), I believe this is not the most appropriate format.
Indeed, operations on Multiaddr (eg.
decapsulate
) actually work on the list of protocols, and not on the byte representation. The bug mentioned in PR #18 is a good example of it.I see two possible representations:
Vec<Addr>
, withAddr
being an Enum for all supported protocolsAddr
and anOption<Multiaddr>
for the inner and/or outer multiaddr.The text was updated successfully, but these errors were encountered: