(feat) Allow Chromecast to be called externally#214
(feat) Allow Chromecast to be called externally#214MGSousa wants to merge 1 commit intovishen:masterfrom
Conversation
|
@MGSousa glad you like the tool! And thanks for the PR! Do you mind splitting this into a couple of PRs to make reviewing a bit easier? As it currently is, it's too big to review since there is lots of changes and I can't tell what is refactoring vs what is making it easier to be called externally by other libraries. And that way I can merge in the changes to make it easier to use, since the refactoring I have some opinions on. Re the refactoring; I am not a fan of this approach in the commands since it adds an extra level of indirection over the code and I'd prefer to see the actual code in the main function of the command: Do you mind reverting these changes to the commands? The other refactoring looks reasonable to me though, but it is hard to tell in this big PR :) |
Agreed, I will try split them up into different PRs.
Yes, it adds an extra level of indirection, but it is needed for the sake of being exported, thus being able to be used externally as a package. import "github.com/vishen/go-chromecast/cmd"
app := cmd.App{
Device: "DeviceName",
Port: 8010,
}
app.LoadApp("appID", "contentID")
app.Pause()
... |
Ah I see, so you're wanting to export the code in the |
|
I actually don't think the For instance there's some duplication in the HTTP server for handling DNS and establishing connections. I also am looking at adding MPRIS/DBUS support but it looks like currently I'd either have to repeat the setup like in the HTTP server, or repeat the setup like in the Since that's something that would/could be used throughout the code base, or even something others could use, it should be exported and made a bit more generic like using a options struct or something instead of passing Cobra cmds. While we're at it @vishen why is it called |
|
@evilhamsterman I agree with your proposed approach, I think having that code somewhere in the application package (or some new package makes sense).
No strong reason here. When I first built it it made sense, but it has since been iterated a lot and the naming could be updated to reflect that. If I were to do it again I would call it |
|
I also made a desktop app for this with a fork of it but the only change is the initial Load timeout (made it configurable) and added useShakaForHls option because I stream transcoded HLS. |
At this moment, I'm using this awesome tool as a Backend on an app that I'm developing, which allows custom control of Chromecast devices from a mobile phone.
With that, I made several, yet simple changes: