-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
Initial DIAL (http://www.dial-multiscreen.org/) client. #2136
Conversation
00a6c21
to
a1e8446
Compare
84c1141
to
cbb5515
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made a few suggestions via commits (take 'em or leave 'em). On namespaces should we use DIAL
for consistency?
Thanks. All looks good to me.
Better not. Better have the same coding style for namespaces as for classes. Which reminds me that |
I think the main reason for upper-camelcase names is consistency to avoid silly typos, although that should be negated using eclipse, etc. It feels more important that the name is correct, which for network protocols means May I suggest we simply add namespace aliases, i.e. |
@slaff I'm doing some revisions to UPnP library which should help to streamline this PR. Should have them out today. |
@@ -7,7 +7,9 @@ | |||
#define WIFI_PWD "PleaseEnterPass" | |||
#endif | |||
|
|||
static Dial::Client client; | |||
namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikee47 I will remove the anonymous namespace. If we apply this change it should be applied to all samples for consistency. Which can be part of a separate PR.
@slaff The Dial::Client is very interesting as it demonstrates behaviour that UPnP::ControlPoint should handle. Specifically, tracking unique service names and fetching descriptions. I could pull that out now, or leave it for another PR? |
@mikee47 Do you mean to create a separate repository for the Dial client? If yes, I will make this. I wanted to change also the naming of one flash variable... let me do it first... |
Or you have meant to put the tracking and fetching of the description from Dial::Client into UPnP::ControlPoint ? If yes - let's finish with this PR and you can make your changes in a separate PR for it. Is that ok for you? |
@slaff I've kind of done it already :-) I'll push the changes and see what you think - also found an important bug in TCP. |
Common code, add `sendRunRequest()` applicationUrl is stored but never changed so just noting the appsUrl seems appropriate, then calculate when required. If I understand the logic correctly, instanceUrl should **only** be set by incoming response. It should therefore not be initialised at all.
This reverts commit 134175d.
…don't store until request queued
27e6592
to
a96d038
Compare
@mikee47 Shall I wait for you or better merge it as it is in |
@slaff I think go ahead and move it, feels like a good place to shove a stick in the mud. |
Allows Sming applications to control remote monitors/TVs.
@piperpilot For example a Sming application can open YouTube on a smart TV and display a video when the BBQ is ready.