This issue is only relevant to people using the JDA client.
Here at FredBoat we are working on separating most of our business logic (mostly commands) from JDA into two different services. The problem with this is that Lavalink-Client is tightly coupled to JDA. I see two solutions to this problem:
Write a generic Lavalink client for the JVM
Heavily modify the existing Lavalink-Client to be generic, with an implementation for JDA
Solution 2 is clearly the easiest solution. The way I see myself doing it would be to make the Lavalink and maybe Link abstract. This would cause breaking changes, but hopefully rather few.
By making Lavalink generic, users will likely also be able to use discord4j and javacord. Feedback is welcome.
This issue is only relevant to people using the JDA client.
Here at FredBoat we are working on separating most of our business logic (mostly commands) from JDA into two different services. The problem with this is that Lavalink-Client is tightly coupled to JDA. I see two solutions to this problem:
Solution 2 is clearly the easiest solution. The way I see myself doing it would be to make the
Lavalink
and maybeLink
abstract. This would cause breaking changes, but hopefully rather few.By making Lavalink generic, users will likely also be able to use discord4j
and javacord. Feedback is welcome.