vimus / libmpd-haskell

A client library for MPD, the Music Player Daemon
MIT License
36 stars 26 forks source link

use of noidle with MPD monad #99

Open matthewleon opened 6 years ago

matthewleon commented 6 years ago

I've been attempting to write a client layer on top of the MPD monad that only uses a single connection to communicate. I'm not sure this is possible if one idles, and am looking for clarification. It appears as though the MPD monad effectively doesn't support the noidle command, as idle blocks the thread, and the monad provides no way to access the underlying socket handle from the outside. Am I correct in assuming that to do this properly, one needs to write an alternative, concurrency-oriented MonadMPD implementation? I am somewhat new to GHC's concurrency support, and wonder if I may be overlooking a potential solution.

joachifm commented 6 years ago

You can get the handle via gets stHandle but that doesn't really help, as you can't conveniently use the handle with a concurrent mpd computation. I don't think there is a good way to do this with the vanilla MPD monad. You could try a concurrent MonadMPD or we could augment the monad with an async like operation.

I'd like to be able to run computations against a connection object, but that'd require some reshuffling ...

matthewleon commented 6 years ago

or we could augment the monad with an async like operation.

I'm leaning toward that option. The sticky aspect of this for me is that idle feels like it should be special-cased in some way, triggering a state change to "idling", such that a "noidle" is needed before executing other commands. I don't see a really clean way of doing this with the current API, though.

joachifm commented 6 years ago

Special casing would be in line with the protocol, so that makes sense.

matthewleon commented 6 years ago

Special casing would be in line with the protocol

In that case, it might also make sense to change the type signatures on idle/noidle.

joachifm commented 6 years ago

My only concern would be complexity, but then I think something like this is probably required given the base design. Will be easier to evaluate if/when there is code to implement the feature.

joachifm commented 6 years ago

See https://github.com/joachifm/nanompd/blob/master/src/MPD/Core.hs#L90 for a simpler base approach, which I believe is much easier to work with (normal async should Just Work), though it shifts more responsibility onto the client implementor.