[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