Re: [mythtv] [mythtv-commits] mythtv/master commit: 45a3bfcd4 by Robert McNamara (rmcnamara)

On 8 February 2012 04:44, Michael T. Dean <[EMAIL PROTECTED]> wrote:

> My preference for external API use is to present the data such that
> clients don't need to know that (currently) 0 means HDTV, 1 means
> WIDESCREEN, and 2 means AVC for program's videoprop, and for
> recordedprogram's videoprop, there are additional values, 3 = 720 and 4
> = 1080 and (as of only very recently) 5 = DAMAGED.  It would also be
> nice if clients didn't need to know that, for dupin values,
> 1=kDupsInRecorded, 2=kDupsInOldRecorded, 15=kDupsInAll, and
> 16=kDupsNewEpi (and other values are invalid--though in 0.24, we also
> had meanings for 32, 64, and 128).  Since we're constantly changing our
> internal values, I don't want clients trying to interpret those values.

Every public APIs used over a networked protocol use numbers or code.
And so should we.
It's also up to us not to constantly break backward compatibility or
that any incorrectly used protocol doesn't break our own code.

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"

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.

>
> I understand the desire to use internal values so the services API (or
> at least datacontracts) can be used for internal code, too, but we have
> to do something so that clients don't have to know these
> constantly-changing MythTV internals.  I think even if we use "external"
> values that are specific to the API--and map them to internal

but the existing code shouldn't be changing in the first place !


> My current thinking is that the best approach would be making it so that
> clients aren't interpreting data at all--but rather displaying it and
> allowing user interaction with it.  At minimum, we need to provide a
> translation between "raw values" and their meanings.  I've created a
> LabelValue datacontract that I'm using with the logging code (which I
> will be pushing soon) to provide label/value pairs for the UI as well as
> "selected" and "active" flags (i.e. for use in drop down lists or

I think this will only resolve a very particular case (like retrieving
text messages) ; but isn't going to help should a fundamental change
be made on the API.

I think it's time we start thinking from the ground up, on how we
should be able to keep backward compatibility at all time, this
includes allowing any version of a frontend to work with any version
of a backend...

That would start by making sure our code can handle communication from
older clients.

I am currently working on an iPhone hardware accessory, the MFI
protocol has evolved over time. But never once broke backward
compatibility.
The first thing a device do is identify the "Lingo" they talk. A Lingo
is the version of the protocol and also define the type of commands.

JY
_______________________________________________
mythtv-dev mailing list
[EMAIL PROTECTED]
http://www.mythtv.org/mailman/listinfo/mythtv-dev