I'm still not on board with the protocol here. It feels broken.
Multistream select's primary operation is reading a length prefixed newline delimited string. Lets call this operation readLpNd().
Interacting with multistream normally just requires calling readLpNd twice, and passing the stream on to someone else. When reading an ls, i'd expect something similar, for example:
numProtos := readLpNd()
for i := 0; i < numProtos; i++ {
proto := readLpNd()
fmt.Println("ls response: ", proto)
}Where the first read reads in a number encoded in either hex or base10 ascii (since the point is somewhat to have human readability).
Instead, I have to do some weird nonsense to read the ls response:
firstline := readLpNd()
lengthOfWholeMessage := readUvarint(firstline) // this value is effectively useless
numberOfProtocols := readUvarint(firstline)
for i := 0; i < numberOfProtocols; i++ {
// same as above
}This just feels rather off, and isnt very user friendly (especially users who might try to manually interact with the protocol)
I'm still not on board with the protocol here. It feels broken.
Multistream select's primary operation is reading a length prefixed newline delimited string. Lets call this operation
readLpNd().Interacting with multistream normally just requires calling
readLpNdtwice, and passing the stream on to someone else. When reading anls, i'd expect something similar, for example:Where the first read reads in a number encoded in either hex or base10 ascii (since the point is somewhat to have human readability).
Instead, I have to do some weird nonsense to read the
lsresponse:This just feels rather off, and isnt very user friendly (especially users who might try to manually interact with the protocol)