Anticipated Nov 2009 Update of RDF/Map/Image Files

[WagonMaster]

I'd say continue leaving them out of the main distribution since they pretty much have to be created and maintained by the extender author.

My preliminary opinion on this subject is conflicted. There are currently 52 RDF files for "extended" remotes in the set that Nils sent me (and about 46 in the current "master" zip file). So I don't want to take them out just yet. But it seems to me like extended RDFs don't really belong in the master set. If I'm thinking about this correctly, the only reason to include RDFs for extended remotes in the master set would be if someone distributes device upgrades using an extended remote, which seems a bit inappropriate to me, but it probably does happen. Am I thinking about this correctly?

To Everyone Reading This: I'd like to hear several more opinions (and any related advice) about whether extended RDFs belong in the master RDF distribution.

Does that mean that Rob would be unable to use the new "master" 15-100 RDF to create a device upgrade with KM? Or is this just a cosmetic issue (i.e. if KM uses button codes and not button names)? If the former, that's a shame because it contributes to the confusion and replication that I'm trying to eliminate. I hope it's the latter.

AFAIK, KM doesn't use RDF's, Maps or Images at all. So you won't break anything. But I'm sure Mike used an RDF (Rob's in the case of the 15-100) to map the buttons originally in KM. So any differences will be cosmetic.

OK, good. Unless I hear otherwise then, I won't worry about replacing Rob's RDF with Dave's RDF in the master set.

Bill

[WagonMaster]

Hmm, it seems I was mistaken. I could have sworn I wasn't getting this when I was looking for updates of certain files.

It's tricky and unintuitive because when you sort by "Last Updated", the files are actually sorted correctly but the displayed date is not the date it used for the sort! So the order is correct, but the displayed dates are not in order! Extremely unintuitive, IMHO. Hoping to hear a response from Rob in this thread.

Bill

[WagonMaster]

Oops! I see Mike snuck in a post (thanks for the input, Mike!) while I was busy composing mine!

OK, so what he says sounds logical to me. I'll plan on including the existing extended RDFs, including any new ones I can "scare up" from various sources. I guess I'll have to go trolling through the "Extenders" section.

As for the KM issue, it sounds like what I said still holds -- I'll safely replace Rob's version of the RDF with Dave's.

Thanks for the help, all!

Bill

[Mark Pierson]

To Everyone Reading This: I'd like to hear several more opinions (and any related advice) about whether extended RDFs belong in the master RDF distribution.

IMHO, the extender RDF's should NOT be part of the master set. A newbie just getting started doesn't need the added confusion of multiple similar files. Once a user ventures into the world of extenders, it's usually for a specific remote which is the only extended RDF they will need.

Perhaps we can have a special folder in the File Section where the latest version of extender RDF's is available. That way, the xRDF's can still be updated as needed but remain available to all in one spot.

[WagonMaster]

A newbie just getting started doesn't need the added confusion of multiple similar files. Once a user ventures into the world of extenders, it's usually for a specific remote (...)

That's a good point.

(...) which is the only extended RDF they will need.

Unless, as I suggested earlier, someone has distributed a device upgrade using an extended RDF (that said newbie wants to use). But is that even a valid concern?

Perhaps we can have a special folder in the File Section where the latest version of extender RDF's is available. That way, the xRDF's can still be updated as needed but remain available to all in one spot.

That sounds like a good compromise to me. Mike? Others?

Bill

[vickyg2003]

Unless, as I suggested earlier, someone has distributed a device upgrade using an extended RDF (that said newbie wants to use). But is that even a valid concern?

I think it is if its a 6131.

It seems to me that when I came back to the JP1 forum, I ran into a problem with an OLD extender rdf not being compatible with IR6 and was told that I should use the one in the official RDF's.

[WagonMaster]

It seems to me that when I came back to the JP1 forum, I ran into a problem with an OLD extender rdf not being compatible with IR6 and was told that I should use the one in the official RDF's.

So which solution would you prefer -- including the extended RDFs with the unextended ones in a single zip file or making them into their own zip file and distributing them alongside the unextended ones?

Also, what you're describing, while still a perfectly valid and related issue, is slightly different than the scenario I postulated. I'm concerned about the case(s) where "Abe", who uses an extended remote, creates and publishes a device upgrade for his PVR. Innocent newbie user "Bob" comes along, wants to use a device upgrade (DU) for the same PVR, downloads Abe's DU file, and, unless we've included the extended RDFs with all the others, suddenly finds that he cannot use Abe's DU and probably won't understand why.

If that scenario is at all valid and likely, then I'd argue that we need to put the extended RDFs in with the others. Otherwise, I like Mark's idea of publishing 2 RDF zip files -- unextended and extended.

P.S. Funny that you mention the URC-6131, Vicky. I happened to be looking at those RDF files just before I saw your post and, unfortunately, it looks like another case that will need some serious head-scratching to resolve the various permutations (and another issue that I'll probably bring up later).

P.P.S. Is it just me or does the forum seem to be responding much better lately, without undue page reloads and stalls?

Bill

[Capn Trips]

All the extenders I know of come with their own custom RDF's. Most have the same signatures as the unextended versions, some don't.

I would have to DISAGREE with this claim. Perhaps a FEW (or maybe even SOME) extender RDFs "have the same signatures as the unextended versions" but certainly not MOST. In fact, BY FAR the majority of extender RDFs have unique signature names.

[mdavej]

My mistake. Post corrected.

In any case, I like the idea of keeping extender RDF's separate from the main distribution.

[vickyg2003]

Unless, as I suggested earlier, someone has distributed a device upgrade using an extended RDF (that said newbie wants to use). But is that even a valid concern?

AFAIK the only place its an issue is if an upgrade was created for a URC-6131 or an Atlas 1054. Upgrades for those two remotes have different versions for extended and base remotes.

I don't think ANYONE was as helplessly confused by JP1 as I was, and yet the word Extender in an RDF wasn't one of those helplessly confusing topics. It just made me go research what an extender was. I like the idea of users developing EXTENDER AWARENESS because extenders are what pushed me into a full blown case of JP1-obsessive-compulsive-disorder. Once I put that extender on my 8811, I HAD TO HAVE those same features on my other remotes. I think extenders are an important part of the JP1 experience.

If I need to unzip two folders, instead of just one, its not really that much of an inconvenience, but if is broken down into 53 zip files, I'd be extremely opposed to having to do all those downloads. I don't want to have to go looking for them like I do now! Even two files seems like it would be confusing.

Are you going to have the maps and images in both files?

I certainly don't think you should go searching for extender RDF's. If an extender is mature the RDF area, either by the extender writer or by a user.

[WagonMaster]

AFAIK the only place its an issue is if an upgrade was created for a URC-6131 or an Atlas 1054. Upgrades for those two remotes have different versions for extended and base remotes.

That's an important angle I hadn't actually directly considered so far (because I wasn't even sure such a case existed) so I'm glad you brought that up. I'd been thinking mostly of the simpler Abe/Bob case described in my previous post.

In other words, I was thinking of a case where the Device Upgrade (DU) writer/publisher just happened to have an extended remote in use when writing the DU, but that the DU didn't really need the extender to operate properly. You're describing another perfectly valid and more serious problem case where the extender is actually required for the DU to upgrade.

I had forgotten what happens in RemoteMaster when such cases (RDF referred to in DU is missing) arise, so to refresh my memory, I just ran RM and attempted to load a DU for which I temporarily deleted the RDF associated with that DU. RM reports the following:

Code: Select all

The upgrade file you are loading is for the remote "RS 15-135"
There is no remote with that exact name.  Please choose the best match from the list below:

Aside: I found what appears to be an unrelated bug in RM while doing that test. I'll open a new thread to address that issue.

So, confronted with that error, the question is: Would a novice user be able to deal with that after trying to load a DU that was "accidentally" (my scenario) or intentionally (Vicky's scenario) written which references an extended RDF?

I'm starting to solidify my opinion that putting the extended RDFs into a separate zip file wouldn't cause undue difficulties here, even to a novice user. For the rare cases where the scenario above happens, I think RM's error message will be enough to cause someone to do the right thing, whether that winds up being (A) finding the proper RDF on the forum themselves (in the 'extended RDF' zip file) or (B) asking for help.

In fact, not seeing a bunch of remotes in the main RM drop-down selection list (or the error message dialog described above) that are derived from "extended" RDFs is probably a good thing for a newbie.

If I need to unzip two folders, instead of just one, its not really that much of an inconvenience, but if is broken down into 53 zip files, I'd be extremely opposed to having to do all those downloads. I don't want to have to go looking for them like I do now! Even two files seems like it would be confusing.

You're probably well outside (in a good way) of the statistical "normal" though, Vicky. I'd be surprised if most people used more than 1 or 2 extenders. Of course, it doesn't really matter because the extender RDFs will be aggregated somehow -- either with the unextended RDFs or in their own zip file. I think we can all agree on that part.

Are you going to have the maps and images in both files?

No, I was not planning to. The map and image files will be distributed together (in the same zip file), but separately from the RDFs, as they apparently have always been. The reasoning here is that, currently, only RemoteMaster (RM) requires the map and image files. Also, since the maps+images zip file is currently almost 10 times the size of the RDF file, I don't think it makes sense (currently) to force anyone to download the maps+images who doesn't use RM. Of course, if other apps started using the map and/or image files, that philosophy might need to change, but currently, it makes sense to me so I plan to continue that way.

I certainly don't think you should go searching for extender RDF's. If an extender is mature the RDF area, either by the extender writer or by a user.

That last sentence doesn't quite parse. I assume you mean "If an extender is mature it will already be in the RDF area, either by the extender writer or by a user."

Assuming I've filled in the missing part correctly, I'm not totally convinced that's true. I'm worried about extenders whose authors are (logically) distributing the extender as 1 packaged zip file, including the RDF, and may not have ever thought (or bothered) to put the RDF into the main "RDF Files" folder. If their extender's RDF was in the "master" file, then they'd have the option of deleting it from their extender's zip file, which is mostly why I'm considering checking what's out there.

Vicky, I know you've written more than 1 extender by now, so I'm interested in your opinion. If you had extender-specific RDFs and I had them in the master RDF zip file, would you retain them in your own published zip file or would you delete them?

Back on the original point, I may not wind up putting any extra (ones not already in there) extender RDFs in the RDF zip file (whether it winds up being part of the main RDF zip or a separate file), but I do still plan to troll through the Extender forum and see what's hiding in the "crevices" out there. It can only lead to a broader perspective and hopefully a stronger RDF distribution. Yes, it will take longer that way, but I think the result will be worth it.

Now, having said that, if anyone finds me including an RDF (extender or otherwise) that they feel is inappropriate for the master distribution (whether because of immaturity, "bugginess", or whatever), then I will be happy to review and remove any inappropriate RDFs. Once the big, ugly, slow job of coordinating and aggregating the myriad of current RDFs is done and published, I don't see any reason why the zip files couldn't be updated as frequently as it may be needed -- even for the addition, deletion, or modification of a single RDF file within.

Bill

[vickyg2003]

I had forgotten what happens in RemoteMaster when such cases (RDF referred to in DU is missing) arise, so to refresh my memory, I just ran RM and attempted to load a DU for which I temporarily deleted the RDF associated with that DU. RM reports the following:

Code: Select all

The upgrade file you are loading is for the remote "RS 15-135"
There is no remote with that exact name.  Please choose the best match from the list below:

Sheesh that happens to me nearly every day. I open a lot of old stuff

If I need to unzip two folders, instead of just one, its not really that much of an inconvenience, but if is broken down into 53 zip files, I'd be extremely opposed to having to do all those downloads. I don't want to have to go looking for them like I do now! Even two files seems like it would be confusing.

You're probably well outside (in a good way) of the statistical "normal" though, Vicky. I'd be surprised if most people used more than 1 or 2 extenders. Of course, it doesn't really matter because the extender RDFs will be aggregated somehow -- either with the unextended RDFs or in their own zip file. I think we can all agree on that part.

Its not so much for MY use. Its for the new "wanna be helpers" and the "curious". We all have different things that draw us into this insanity. You and I are good examples of that. You are "into the technical stuff" and I'm into the "automation and clean coffee table stuff". I'd often pop in to the forums and look at people's IR files when they were having trouble. If the extender RDF's were difficult to obtain, I'd have a serious bar to helping people and I think the next group of volunteers would be impeded too.

I certainly don't think you should go searching for extender RDF's. If an extender is mature [it is in ]the RDF area, either by the extender writer or by a user.

That last sentence doesn't quite parse. I assume you mean "If an extender is mature it will already be in the RDF area, either by the extender writer or by a user."

Assuming I've filled in the missing part correctly, I'm not totally convinced that's true. I'm worried about extenders whose authors are (logically) distributing the extender as 1 packaged zip file, including the RDF, and may not have ever thought (or bothered) to put the RDF into the main "RDF Files" folder. If their extender's RDF was in the "master" file, then they'd have the option of deleting it from their extender's zip file, which is mostly why I'm considering checking what's out there.

Vicky, I know you've written more than 1 extender by now, so I'm interested in your opinion. If you had extender-specific RDFs and I had them in the master RDF zip file, would you retain them in your own published zip file or would you delete them?

Its the practice to package your RDF with the extender. I do believe the documentation says to look for updates in the master file, but that doesn't matter. I have RDF's in the master file, and they are missing corrections that I have submitted on more than one occasion. I'll update my RDF's in my zip files with changes to keep them current, but there is no way I'd delete them from my Zip file. I would hate to have my extenders broken by bad RDF and then have to try to figure it out without a good version.

On all of MY extenders, if an RDF change was needed, I changed the signature, but am pretty sure unclemiltie doesn't follow that practice, and some extenders don't change the signature at all because the remote fights the signature change.

Back on the original point, I may not wind up putting any extra (ones not already in there) extender RDFs in the RDF zip file (whether it winds up being part of the main RDF zip or a separate file), but I do still plan to troll through the Extender forum and see what's hiding in the "crevices" out there. It can only lead to a broader perspective and hopefully a stronger RDF distribution. Yes, it will take longer that way, but I think the result will be worth it.

I really feel that's a bad idea. But you should check with unclemiltie. I think this is going to break his JP1.3 extenders, but I'm not sure.

[WagonMaster]

If the extender RDF's were difficult to obtain, I'd have a serious bar to helping people and I think the next group of volunteers would be impeded too.

I agree. So if you're just clarifying that my suggested plan will work OK for you, then I understand. If you're suggesting otherwise, then I don't follow you because I'm saying that the extended RDFs will be aggregated... maybe with the unextended RDFs' zip file and maybe in their own zip file. But they won't be scattered all over for people to have to go and collect in pieces. So, as far as I can tell, we basically agree, right?

I have RDF's in the master file, and they are missing corrections that I have submitted on more than one occasion.

Of course, that should not be happening. I don't doubt you for a second. What I'm saying is that if that is happening too often, "yell" at the maintainer! Now that I'm the maintainer, my advice is the same. Don't worry, I can take it. And if the maintainer is AWOL, then, in theory, you've already submitted your updated RDF to the "RDF Files" section, right? If not, then you should have. So even though the maintainer may have missed it in the last update or been AWOL, the users still have access to it (in a common, central location), which is what really matters.

I'll update my RDF's in my zip files with changes to keep them current, but there is no way I'd delete them from my Zip file.

OK, good. Thanks for your input on this -- that's helpful for me to know. Now I know that whatever extended RDFs that I put into the "master" list, they cannot ever truly be considered the master since your RDFs (and probably other authors' RDFs) will continue to exist apart from the masters. I'm OK with that (do I have a choice? ) because at least I know now to always treat the extended RDFs in the master file as "for users' convenience only" and I can advise people accordingly.

What's unfortunate is that it means that the project will seem to have conflicting philosophies whereby (per your own comment above) we may be telling people in the extenders' documentation "to look for updates in the master file" on one hand and yet if any author (not trying to put the blame on your shoulders, since I suspect many others would agree with you, Vicky) decides to maintain/publish their own extender's RDF, we're really implicitly training users to treat that as the latest RDF. Which means that we'd be potentially devolving into the exact situation that you said earlier you wanted to avoid -- having to grab extender RDFs from a myriad of places.

Having said all that, I don't think that changes my plan, though. To my mild chagrin, the master extended RDF file may or may not have the latest RDF for any given extender, but it will be there for the convenience of extender users and people who might just want to help them.

I think this is going to break his JP1.3 extenders, but I'm not sure.

Sorry, you've lost me there. How can my inclusion of Bill Jackson's own RDFs into the master extended RDF file break his extenders? Please clarify. If there's any danger of breaking anything, I will certainly check with him (once I've had a chance to see how his extenders' RDFs compare to the ones I got from Nils).

Bill

[mathdon]

If you want another view about extender RDFs, I strongly advocate having all RDFs, for both unextended and extended remotes, in the same main zip file. It doesn't matter that extenders are distributed together with their RDFs, the issue is whether one can open a .ir file from an extended remote without having to download the extender.

There are all sorts of reasons for opening a .ir file for a remote one doesn't have. As Vicky says, there are the "wanna be helpers" and the "curious", but it is something that anyone who wants to broaden their knowledge of the JP1 world will do. The more difficult it is made to do this for files from extended remotes, the fewer the number of new helpers and knowledgeable users will be. It will certainly discourage the use of extenders.
____________
Graham

[mr_d_p_gumby]

I'm equally divided on the merits of one vs. two RDF zip files. There are advantages and disadvantages to both approaches.

Re: Abe's extender-based DU being loaded by Bob
Abe is probably not a novice user, since he is using an extender after all (assuming he did not use an extender RDF by mistake). With a few exceptions, a device upgrade will not be any different if created with or without an extender. The main advantage to Abe is the ability to assign functions to keys which would not be defined in the non-extender RDF. These assignments would in most (but not all) cases generate keymoves. Only the Atlas/URC-6131 extenders treat keymoves differently than the non-extended versions.

Advantage: single RDF zip file. Bob loads the upgrade uneventfully and can continue as expected.

Disadvantage: two RDF zip files. Bob gets the error message shown below. Being a newbie, he has no idea of the significance of the words "extender" or "eeprom", and is stymied. He posts a "Why am I getting this error?" question in the forum, and is frustrated because he cannot continue until someone responds to his question.

Code: Select all

The upgrade file you are loading is for the remote "Radio Shack 15-2133 Extender 1 (32K eeprom)" 
There is no remote with that exact name.  Please choose the best match from the list below:

If Bob is astute enough to select the nearest matching remote, the worst that can happen is that the function-to-button assignments in the upgrade are lost. Since he is most likely to be changing the upgrade to a different remote, this might happen anyway. If he is following directions, he should re-do the assignments to his liking.

Re: Bob creating a new upgrade for a remote with many RDF files
Advantage: two RDF zip files. In most cases, Bob will only be presented with one RDF for his remote.

Disadvantage: one RDF zip file. Bob is potentially presented with a large number of choices when he tries to select his remote. Being a newbie and not knowing the significance of "extender", he is confused and posts a question in the forum (this has happened). Again, he is frustrated because he cannot continue until someone responds to his question.

One possible area of confusion regarding the two-ZIP solution is that existing documention scattered all over the JP1 community directs the user to download the main RDF zip file, and will not mention that extender RDF files are in a separate ZIP file. Ideally, such documentation should be updated, but I would think most extender users would be astute enough to realize that they need to download the extender ZIP as well.

At this point, I'm inclined to await further discussion on the subject before voting one way or the other. (Just what you wanted to hear, Bill, right? )

I'll update my RDF's in my zip files with changes to keep them current, but there is no way I'd delete them from my Zip file.

OK, good. Thanks for your input on this -- that's helpful for me to know. Now I know that whatever extended RDFs that I put into the "master' list, they cannot ever truly be considered the master since your RDFs (and probably other authors' RDFs) will continue to exist apart from the masters. I'm OK with that (do I have a choice? ) because at least I know now to always treat the extended RDFs in the master file as "for users' convenience only" and I can advise people accordingly.

Vicky, I think you are corect in the sense that an extender distribution always contains the RDF file that the author used to test the extender, and that RDF file should always be updated as much as is possible. But that does not preclude distributing a newer RDF in the main RDF ZIP(s). This has often happened in the past. In some cases, the extender author no longer frequents the JP1 forum, and in the meantime the JP1 tools have been upgraded (Special Protocols comes to mind here). There is no chance the original author is ever going to update the RDF in the extender distribution, so the only way an upgraded RDF can be distributed is via the main ZIP(s).