ls protocol format is unfriendly

[whyrusleeping]

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)

[whyrusleeping]

Its also really inconvenient to create these messages.

[daviddias]

Although ease of implementation is super valuable, is it worth to create a breaking change in the spec now?

[whyrusleeping]

Yeah, as far as i can tell nobody uses multistream ls. the only tool (mss-nc) that can easily ls things doesnt follow the spec anyways

[creationix]

If all messages are text based, I think newline delimited is much better for implementations and for testing with tools like nc.