JP1 Remotes

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

Other than embedding the version number in each RDF, or actually reading the RDFs directly out of the ZIP file without extracting (which wouldn't be too hard for RM, BTW), there is no way to ensure that the user won't stick an old RDF from who knows where in with the released RDFs.

This, however, is a problem that we already have, and adding a separate version file doesn't make it any worse.

There is one thing we could do to reduce the odds of people using outdated RDFs: go back and repackage all the extenders so that none of them include RDFs. It seems to me this is the primary source of incompatible RDFs.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

Mark Pierson · Posted: Tue Sep 07, 2004 7:27 pm Post subject:

I guess I'll make the argument again for changing the RDFSync entry each time there's a major revision to IR and/or RM that relies on a minimum compatable version. When I suggested this last time, it was shot down. Sad

However, the flag is already in the RDF spec and files, and IR currently won't open and use anything less than RDFSync=3 without an error message. Granted, it would still be a pain to update them all when necessary.

Then again, a simpler approach might be to include the version number in the filename, i.e."RSL6RSL0 (RS 15-1994 6-in-1 Smart).117.rdf". That wouldn't overwrite files, so there'd be a housekeeping issue for users unless updates were somehow automated.
_________________
Mark

pgk · Joined: 21 Aug 2004 Posts: 113 Location: London

mr_d_p_gumby · Posted: Wed Sep 08, 2004 11:29 am Post subject:

Nils_Ekberg · Posted: Wed Sep 08, 2004 3:00 pm Post subject:

I am liking most of these ideas and fundamentally don't have a problem adding a new item to the [General] section of each RDF and actually think it is the right way to go.

I also think we should add either two items or one with 2 values.. Value one would be the last revision date and value two would be the zip file release value like V1.17.

What I am getting at is having two values, one of which tells us which zip file it came out of and the other telling us when it was actually last revised. A lot of times I go by the file date for diagnostics and adding and revising an item would overwrite the file date. This way whoever modifies an RDF would also need to change the revision date or I would just do that when I packaged a new or revised RDF.

I would also add that these values should not be added to an RDF unless it is distributed in the RDF zip file.. That way if the RM or IR file does not have any information we know it is either a beta or extender RDF.

The Robman · Posted: Wed Sep 08, 2004 4:18 pm Post subject:

I've got an idea that's actually a mixture of all of the above. I think we should include a version file in the zip that indicates which release of the zip file is being used. In addition to this, I think there should be an entry in each RDF that indicates what version the RDF itself is. This last version number would only be updated when this particular RDF is updated for some reason (which of course, is rare).

I think the RDF version number should be a two part number (like 1.23) so that whenever a major change comes along where all the RDFs need to be updated, the first number would be incremented and the second number reset to 00 (so my 1.23 number would become 2.00). Then, whenever a correct or other update is done to this RDF in particular, the secondary version number would be incremented.

Then using Mike's example, let's say the current RDF version for the 15-1994 is 2.13 and a bug is discovered. When the bug is fixed, the version for this RDF alone becomes 2.14. Then when the next guy comes along reporting the same bug over again, we ask him for his version number which will tell us that he's not using the updated RDF.

If IR.exe were to display both numbers somewhere, we could tell that the user is (a) using the current zip file and (b) is using the current version of the relevant RDF.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

e34m5 · Joined: 14 Oct 2003 Posts: 675 Location: Atlanta

I'm not sure what the value of the zip version is. I'm one of those who only extracts the RDF's needed. So for me the only value that would matter is the version of the RDF itself.

As far as showing this in IR it's not an issue what so ever.
_________________
Paul

The Robman · Posted: Wed Sep 08, 2004 8:43 pm Post subject:

Only extracting a few RDFs from the official zip is a potentially problematic thing to do, so while I'm confident that you know what you're doing, I wouldn't want to encourage others to do the same.

Therefore, the zip version tells us that the user has downloaded the current zip file. Granted, this isn't as important as the individual RDF versions, but it would give us the chance to tell that user that they should download the current zip.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

pgk · Joined: 21 Aug 2004 Posts: 113 Location: London

Sounds like we need a mixed approach.
e.g.

3 new items in the RDF.

Source=<Source of RDF>
Release=<RDF Version>
Revised=<Revision Date>

1 new file in RDF zip for version of zip file.

The source field could then be used as a freeform string to determine where the file originated. e.g. "Extender 2" or "RDFs 117.zip" or "Msg 10000" or whatever.
The release would be as Rob put forward an RDF specific release.

This would give a fair level of detail, and the software can use "Unknown" ot something if the item isn't present.

The only other thing I can think of which could be useful, but would probably be overkill, is some sort of checksum/crc/hash to indicate the content hasn't been changed, since the fields themselves rely on people actually updating them properly. (Checksum not present/not matching wouldn't be a cause to reject the RDF just a bit more information, since we'd know those with valid checksums probably have the other information correct also)

e34m5 · Joined: 14 Oct 2003 Posts: 675 Location: Atlanta

The Robman · Posted: Thu Sep 09, 2004 7:40 am Post subject:

Because sooner or later they're going to try doing something and they'll end up using an out of date RDF and they'll have problems. Then they'll come here and post their questions taking up alot of our time, for us only to discover in the end that they're using an out of date RDF.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

e34m5 · Joined: 14 Oct 2003 Posts: 675 Location: Atlanta

We are talking two different things. I agree with you in terms of the version of the RDF in question. I was only referring to downloading all the RDF's. I do not see any need for that.

In my previuos job we simply used the date on the file as the version. So all we would need to do is add a "Created Date"in the RDF.
_________________
Paul

zaphod7501 · Joined: 02 Aug 2004 Posts: 534 Location: Peoria Illinois

I don't know if this applies , but what would happen if you opened a posted file from the Yahoo groups and there was no RDF to match the poster's upgrade on your computer ? When I open a Keymaster file with RemoteMaster , it asks me to choose between a limited selection of remotes. Does it get these from the RDFs or is it internal to RM ?
_________________
Just call me Zaphod (or Steve) --- I never should have started using numbers in a screen name but I just can't stop now.

e34m5 · Joined: 14 Oct 2003 Posts: 675 Location: Atlanta

IR shows a message that the required RDF is not present.
_________________
Paul

The Robman · Posted: Thu Sep 09, 2004 9:03 am Post subject: