|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
unclemiltie Expert
Joined: 21 Jan 2004 Posts: 1795 Location: Pittsburgh, PA |
Posted: Thu Dec 02, 2010 11:23 am Post subject: An idea for Extender RDF's |
|
|
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? _________________ this JP1 stuff is a sickness! |
|
Back to top |
|
|
Capn Trips Expert
Joined: 03 Oct 2003 Posts: 3990
|
Posted: Thu Dec 02, 2010 1:26 pm Post subject: |
|
|
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 _________________ Beginners - Read this thread first
READ BEFORE POSTING or your post will be DELETED!
Remotes: OFA XSight Touch, AR XSight Touch
TVs: LG 65" Smart LED TV; Samsung QN850BF Series - 8K UHD Neo QLED LCD TV
RCVR: Onkyo TX-SR875; Integra DTR 40.3
DVD/VCR: Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A3 (HD-DVD), Panasonic AG-W1 (Multi-system VCR);
Laserdisc: Pioneer CLD-D704.
Amazon Firestick
tape deck: Pioneer CT 1380WR (double cassette deck)
(But I still have to get up for my beer) |
|
Back to top |
|
|
xnappo Expert
Joined: 30 Dec 2003 Posts: 861
|
Posted: Thu Dec 02, 2010 1:38 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21234 Location: Chicago, IL |
Posted: Thu Dec 02, 2010 2:04 pm Post subject: |
|
|
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. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1414 Location: Munich, Germany |
Posted: Fri Dec 03, 2010 3:45 pm Post subject: Re: An idea for Extender RDF's |
|
|
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 |
|
Back to top |
|
|
unclemiltie Expert
Joined: 21 Jan 2004 Posts: 1795 Location: Pittsburgh, PA |
Posted: Fri Dec 03, 2010 4:09 pm Post subject: Re: An idea for Extender RDF's |
|
|
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. _________________ this JP1 stuff is a sickness! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1414 Location: Munich, Germany |
Posted: Sat Dec 04, 2010 4:31 am Post subject: Re: An idea for Extender RDF's |
|
|
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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|