-
Notifications
You must be signed in to change notification settings - Fork 92
(feat) Allow Chromecast to be called externally #214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
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 |
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: