Open matthewleon opened 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 ...
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.
Special casing would be in line with the protocol, so that makes sense.
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
.
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.
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.
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 oneidle
s, and am looking for clarification. It appears as though theMPD
monad effectively doesn't support thenoidle
command, asidle
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-orientedMonadMPD
implementation? I am somewhat new to GHC's concurrency support, and wonder if I may be overlooking a potential solution.