[mythtv] [mythtv-commits] mythtv/master commit: 45a3bfcd4 by Robert McNamara (rmcnamara)
Stuart Morgan
stuart at tase.co.uk
Tue Feb 7 22:52:52 UTC 2012
On Wednesday 08 Feb 2012 09:40:04 Jean-Yves Avenard wrote:
> That it's a number or a name makes no difference whatsoever
>
> As long as the protocol is documented, I don't see the problem in
> using numbers ; quite the opposite.
>
> I don't see why a protocol should be using "user friendly" value, it's
> not going to be seen by a user, only a dev.
> And if properly documented, a "1" is just as clear as using
> "ThisIsMyUserFriendlyTypeCommand"
Which is fine so long as 1 always means the same thing, which may not be the
case, especially with internal enums where the actual numbering frequently
changes as new items are added to the enum. This is why we reference values in
an enum by their name and not their numerically equivalent value. Why expect
third party applications to do something we're not even doing internally?
> TBH, I found deplorable the approach of having to use a particular
> code, just for an application to be allowed to communicate with myhth
> and specifically working and adding code to block those apps from
> working.
The apps broken by that change were faking support for protocol versions they
didn't actually understand. As a result they were liable to cause serious
operational problems for the backend and/or corrupt users data. We didn't add
the string to block third parties using the _internal_ protocol, we just in
effect changed the protocol version from a guessable number to a random token.
Now if applications want to use the internal protocol their developers have to
at least read the source code and hopefully support that protocol version not
one from 3 years ago.
--
Stuart Morgan
More information about the mythtv-dev
mailing list