Misleading documentation about lavalink HOT 7 CLOSED

Should probably make a point that, while endTime is documented, it doesn't affect anything; i.e., there's no actual code that does anything with it if received.

from lavalink.

this leads to a small issue

What kind of issue? Longs being encoded as strings and not numbers in JSON is correct, since JSON numbers have an undefined bit size and many implementations only use 53 bits of precision for JSON numbers (which is lower than the 64 bits of Java Longs).

from lavalink.

lavalink itself is okay with it (surprisingly), but the documentation is still misleading. not a lavalink issue in general, but clients sending numbers as strings where it's consistent everywhere else in the docs can lead to local issues in clients for their users (for example, the positions in play payloads are strings but in seek payloads they're numbers).

if you test your lavalink client with something like andesite which is almost entirely compatible with lavalink, it will throw an error because it expects longs over strings (like it should, logically). but that isn't a lavalink issue.

• client api's seem weird unless you add convenience methods. misleading and wasted performance
• documentation is consistent everywhere else besides this
• causes issues with other applications that claim to have lavalink compatibility.

either way, removing four characters from the documentation for those benefits seems super worth it and makes client developers a little happier too

from lavalink.

the positions in play payloads are strings but in seek payloads they're numbers

That's just a consistency issue with seek, and not a misleading example of play

it will throw an error because it expects longs over strings (like it should, logically)

A proper JSON parser should be able to parse strings as longs when longs are expected. It is common practice to specify large numbers as strings.

client api's seem weird unless you add convenience methods. misleading...

Clients should represent these numbers as close to 64 bit signed ints as possible

...and wasted performance

The time it takes to convert an integer to a string is extremely short, and not worth optimizing for.

from lavalink.

Of course, one can argue why it is even relevant to use longs for track times. Longs were chosen just because Lavaplayer uses them.

from lavalink.

If there are other 64bit Longs shown as JSON numbers in the implementation then that should probably be changed to be JSON strings, imo.
If your JSON parsing client is exploding because it refuses to parse a Java Long from a JSON string even though it is a valid Long that's an issue with your JSON parsing client. For popular clients like Jackson these types of parsing options are usually solved by setting a flag.
Another popular example for 64 bit numbers transported as JSON strings are Discord snowflakes.

from lavalink.

endTime is used nowadays https://github.com/freyacodes/Lavalink/blob/a3648335bc8838cb7d6cff6b5caacce35e3a70b1/LavalinkServer/src/main/java/lavalink/server/io/WebSocketHandlers.kt#L65

I don't see anything here that needs to be fixed

from lavalink.