JP1 Remotes

There has been an ongoing discussion about Extender RDF's and this topic has boiled back to the top of my mind and I have been thinking about it.

Anyway, what if we did something like this:

In the RDF directory, there are two RDF's as we have today, let's use the Atlas for example:

30333033 is the unextended RDF
3A333A33 is the extended RDF

Now, instead of the extended RDF duplicating everything that is in the unextended RDF, the extended RDF has a reference to the unextended RDF (as some others have done to make the maintenance easier)

OEMRemote = 30333033

What this does is tell the tools that for everything that is not specified in this RDF, go get it from the unextended RDF. That way there is a button list, valid setup code list, protocol list, etc that doesn't have to be maintained twice. The extended RDF's would only specify those things that are different.

We could then also include the extender hex code into the RDF so that IR/RMIR can do a "new" for the extended remote and could incorporate what Extinstall does directly. Some form of tag that signals that this is the hex file for the remote. Ideally waht followed would be the output of the assemblers that we extender writers use so that no intermediate conversion would need to be done. (i.e. the contents of the HEX file for the Samsung processors)

This way, we get a couple of benefits:

1: easy to maintain and consistency between the unextended and extended RDF's. If the unextended remote changes (i.e. someone decides that a protocol is a different variant) then both are changed at the same time.

2: less stuff to distribute with an extender. We're now down to a stripped down RDF and a users manual. Install the RDF into the RDF directory and read the book.

3: the benefit of a "new->remote" with the extender in it

This will require work on the tools part. The good thing is that if the new RDF doesn't reference the unextended RDF and is completely specfified then there should be no issues. And Extinstall will still work as it does today, so we don't have to go back and back-port everything.

thoughts?

I like the concept, especially insofar as the RDF maintenance issue, where folks have been (appropriately) reluctant to modify extender RDFs if they were not the author, despite it occasionally being required.

As long as the other affected tools (RMIR and IR, I suppose) can be modified to use this paradigm

Capn Trips wrote:I like the concept, especially insofar as the RDF maintenance issue, where folks have been (appropriately) reluctant to modify extender RDFs if they were not the author, despite it occasionally being required.

As long as the other affected tools (RMIR and IR, I suppose) can be modified to use this paradigm

As the RDF librarian, I think this is a good idea. Unnecessarily duplicated data is never a good thing.

Question is of course the tool support. And should it still be called .rdf or should we do something like .xdf to differentiate?

xnappo

I like all of the ideas in this thread, but of course, that means nothing if Greg and Graham don't want to change RM and IR to handle it.

Thank you very much for your contribution Uncle"

Actually, it is not one suggestion, but two. These can and should be treated separately. First one is about inheritance:

unclemiltie wrote:Now, instead of the extended RDF duplicating everything that is in the unextended RDF, the extended RDF has a reference to the unextended RDF (as some others have done to make the maintenance easier)

OEMRemote = 30333033

What this does is tell the tools that for everything that is not specified in this RDF, go get it from the unextended RDF. That way there is a button list, valid setup code list, protocol list, etc that doesn't have to be maintained twice. The extended RDF's would only specify those things that are different.

This is not tied to extenders (except that extenders is the primary usecase). To maximize usability I would suggest using filename (without directory) instead of RemoteID, and using a keyword like "InheritFrom" instead of "OEMRemote". An inheritance mechanism like this would be a great improvement. It does not need to be implemented as extension to RM/IR but can also be implemented as a preprocessor, although probably the first alternative would be advantageous.

The second suggestion is to relocate the definition space of the very extender code to the RDF:

unclemiltie wrote:We could then also include the extender hex code into the RDF so that IR/RMIR can do a "new" for the extended remote and could incorporate what Extinstall does directly. Some form of tag that signals that this is the hex file for the remote. Ideally waht followed would be the output of the assemblers that we extender writers use so that no intermediate conversion would need to be done. (i.e. the contents of the HEX file for the Samsung processors)

If this is doable (I am not able to tell) it wold be a great step forward in extender maintainance. Question is of course if someone is willing and able to implement it.

Bengt

Barf wrote:Thank you very much for your contribution Uncle"

Actually, it is not one suggestion, but two. These can and should be treated separately. First one is about inheritance:

unclemiltie wrote:Now, instead of the extended RDF duplicating everything that is in the unextended RDF, the extended RDF has a reference to the unextended RDF (as some others have done to make the maintenance easier)

OEMRemote = 30333033

What this does is tell the tools that for everything that is not specified in this RDF, go get it from the unextended RDF. That way there is a button list, valid setup code list, protocol list, etc that doesn't have to be maintained twice. The extended RDF's would only specify those things that are different.

This is not tied to extenders (except that extenders is the primary usecase). To maximize usability I would suggest using filename (without directory) instead of RemoteID, and using a keyword like "InheritFrom" instead of "OEMRemote". An inheritance mechanism like this would be a great improvement. It does not need to be implemented as extension to RM/IR but can also be implemented as a preprocessor, although probably the first alternative would be advantageous.

The reason I reference the signature is that is the way that all of the tools reference the RDF's today. (i.e. when a remote is downloaded, IR will read the signature and load the appropriate RDF. Extinstall works this way as well. It reads the IR files, and then picks up the right RDF's to match what it finds in the signature. ) This is the basis of the RDF file name and uniquely identifies the RDF. Any other mechanism of inheritance is fine with me, but I wanted to keep things the way that people are used to working at this point.

unclemiltie wrote:The reason I reference the signature is that is the way that all of the tools reference the RDF's today.

This is an argument. My idea (shame on me for not writing it out and instead referring to it as "to maximize usability" ) was to allow inheritance from a rdf-fragment; a file that is not in itself a complete rdf. (Cf. abstract classes in object oriented programming.) This would give rise to a powerful method of structuring future rdf-files, without resorting to a macro preprocessor, with all its quirks.

The best solution would probably be to have both "InheritFromRDF" (with semantics as before) as well as "InheritFromFile" reading from a file name given as argument.