New IR file format

[Mark Pierson]

The advantage to seperate sections for each key move is that future enhancements are limitless. New keys can be defined as the needs arise. We can still have a [Key Moves] section that could be a simple enumeration of exisiting key moves (one entry per defined key move), i.e.:

[Key Moves]
1=<BoundDev>:<BoundKey>
2=TV:TV/VCR
...
n=<BoundDev>:<BoundKey>

Then, for each entry, there could be an individually named section with the details as I suggested above, i.e.:

[TV:TV/VCR]
Notes=Toggles input from ANT to LINE
Upgrade=TV/1234
NewFeatureNotThoughtOfYet=Details go here

If IR is using the Delphi .ini classes to read and write the files, most of the hard work is already done, it's just a matter of parsing it out properly.

[e34m5]

Well I think this would add unnecessary complexity. The reason I made the format that way is that the INI class is designed to read all the keys in a section at one time.

This allowed me to just load all the corresponding notes into memory for KM, Macros, etc in one shot. And then correspondingly saving them out of memory on one shot.

What you are suggesting, although doable will cause a double read. The KM section would be more like a meta data list and then the actual data would need to be retrieved from the detail section.

So I can do this of course, we just need to decide if this is the format we want to use.

Maybe the thing to do is have another section for [UPGRADES]. The keys would be the setup code perhaps. Or what ever the main identifier needs to be.

And then we just keep adding sections as required...

[Mark Pierson]

I understand (somewhat) about the double-read, but wonder if any performance hit would really be noticeable from the UI?

Again, my reason for suggesting this format is for future expansion needs. If we decide that some kind of flag is needed to determine where a key move came from (part of an upgrade, etc), then that would need to be coded somehow in the current ini key entry, which would then need to be parsed out, which wouldn't be any worse than a double-read, would it? Not to mention what we do when there's more items associated with any given key move we want to track.

It just makes sense to me since the .ini format is so well suited for this type of thing. Of course, if and when IR leaves the Windows platform, reading the files won't be quite so easy (I'm not sure if Java, etc, has .ini-type classes, for example).

[e34m5]

I doubt there is any performance hit at all. This is all local and I just load everything into memory and while IR is open it's all handled in memory.

I can code this. Just need a little time. We need to mockup and INI so we are all in agreement.

We also need to decide what to do with existing IR files. We would need to convert those automatically.

If you have time how about taking your existing IR file and completely mock it up. That would give a real good roadmap to use.

As far as JAVA is concerned it's text capabilities stink.

[Nils_Ekberg]

Yeah, I agree. If and when this goes to Java they will have a real hard time reading the file if we went with the full INI format. I would get concerned if we use the INI format beyond simple section headings because it could be real difficult managing where one button ends and the next starts since there is potential that the sections could be a different number of lines depending on what kind of keymove it was. If we stay with the single delimited line format we could save a lot of work in the future.

Paul, I also think there may be some performance hit when the file is opened since you would have significantly more data to read because of the additional tag names. The ones that would feel it are those with older and slower systems

[e34m5]

I really don't think there will be any performance hit. Text files are read very clean when it comes to read/write. In fact that is why they work so well even in low end systems.

As far as sections are concerned they would have to be consistent. In other words the details section for KM or Macros would always need to have the same number of keys, something like this that Mark suggested

[TV:TV/VCR]
Notes=Toggles input from ANT to LINE
Upgrade=TV/1234
NewFeatureNotThoughtOfYet=Details go here

(fyi..in case you didn't know the keys are all the items under the section, like Notes, Upgrade, etc)

The reason it works so well is because the call from the INI class can read all the keys in one call.

So long as we can keep this consistent we should not have any problems with delimiting the information.

[e34m5]

Ok. After talking to Nils I think I undestand. You both want the same thing but via different methods.

Here is my suggestion..

Currently the KM section looks like this

[KeyMoves]
TVREC:0039=Pause
RCVRPHANTOM1:2023=discrete ON
RCVRPHANTOM2:2023=discrete OFF

Where the key is defined as -
BoundDevice:DeviceCode:BoundKey:SetUpCode

My suggestion would be to add one more section to the key -
BoundDevice:DeviceCode:BoundKey:SetUpCode:UpgradeFlag

Advantages would be as follows:

- Easy to implement in code
- No implicit conversions of existing files would be required. The "Save"
would automatically add the last piece.

Mark - I guess the main difference is in how we are interpreting the storage of the data. I look at it more from normalized perspective. I think you were perhaps looking for a file that was more friendly for humans to read. In my case having come from the database side it makes more sense to keep all like info together.

I would also recommend that we add a column to the KM grid to flag if the KM is part of an upgrade or not. A blank value would indicate that the KM was "User Created".

Additionally we can always add more sections for other information

Having said that I'm open to all possibilities.

[Mark Pierson]

Where the key is defined as -
BoundDevice:DeviceCode:BoundKey:SetUpCode

Not to sidetrack here, but isn't there a piece of information missing from this definition? The DeviceCode is the setup code associated with the BoundDevice. However, there's no reference to the DeviceType of the specified SetupCode (which doesn't have to be the same as the BoundDevice). That surely is needed if we ever want to implement auto-deletion of key moves.

On the other hand, it still seems to me that the only info needed to construct the 'key' is the BoundDevice:BoundKey, since the rest can be inferred from the key move hex directly (for key moves, the BoundKey is the 1st byte, the device index (BoundDevice) is specified in the high side of the 2nd byte, while bytes 3 & 4 specify the device type/setup code).

My suggestion would be to add one more section to the key -
BoundDevice:DeviceCode:BoundKey:SetUpCode:UpgradeFlag

Pardon my ignorance, but shouldn't all the data be on the right side of the equal sign? Isn't the key meant to be just an index to the data?

Mark - I guess the main difference is in how we are interpreting the storage of the data. I look at it more from normalized perspective. I think you were perhaps looking for a file that was more friendly for humans to read. In my case having come from the database side it makes more sense to keep all like info together.

Yes, the HRF factor did enter into my thinking, but it was driven more by my understanding of how ini-type files are handled.

I would also recommend that we add a column to the KM grid to flag if the KM is part of an upgrade or not. A blank value would indicate that the KM was "User Created".

Again, pardon my ignorance. Can someone tell me the difference between a key move created by KM/RM as part of a device upgrade (as a user convenience) and that same key move entered directly in IR by the user? In my mind, in either case, it's "part of" the corresponding upgrade... how it got into IR is irrelevant. Why would you auto-delete one and not the other?

Additionally we can always add more sections for other information

Doesn't that go against the argument you guys have been giving me for my suggestion? Based on what you're saying here, if we want to add another piece of stored data for a key move, it will have to somehow be integrated into the appropriate entry in the [Key Moves] section, such as the UpgradeFlag, correct?

I'm not trying to be argumentative here; I just want to see the proper format used (whatever it may be) if we're going to proceed with this. I'm just tying to think "down the road" as opposed to "here and now".

[e34m5]

Where the key is defined as -
BoundDevice:DeviceCode:BoundKey:SetUpCode

Not to sidetrack here, but isn't there a piece of information missing from this definition? The DeviceCode is the setup code associated with the BoundDevice. However, there's no reference to the DeviceType of the specified SetupCode (which doesn't have to be the same as the BoundDevice). That surely is needed if we ever want to implement auto-deletion of key moves.

That could be made part of the key as well

On the other hand, it still seems to me that the only info needed to construct the 'key' is the BoundDevice:BoundKey, since the rest can be inferred from the key move hex directly (for key moves, the BoundKey is the 1st byte, the device index (BoundDevice) is specified in the high side of the 2nd byte, while bytes 3 & 4 specify the device type/setup code).

You are correct only the BoundDevice:BoundKey is the minimum for a KM identification. I believe Nils was thinking down the road when he suggested the rest. In fact that is how I had originally defined it.

My suggestion would be to add one more section to the key -
BoundDevice:DeviceCode:BoundKey:SetUpCode:UpgradeFlag

Pardon my ignorance, but shouldn't all the data be on the right side of the equal sign? Isn't the key meant to be just an index to the data?

The data is to the right of =. What I was referring was simply to change the key and leave the data as the note

Mark - I guess the main difference is in how we are interpreting the storage of the data. I look at it more from normalized perspective. I think you were perhaps looking for a file that was more friendly for humans to read. In my case having come from the database side it makes more sense to keep all like info together.

Yes, the HRF factor did enter into my thinking, but it was driven more by my understanding of how ini-type files are handled.

I was factoring both into this comment. But for me the section is like a table. ie KM info goes in one table..Macro info in another...Upgrade info in another and so on. Each table has a key field (like the KM definition) that becomes a foreign key to the other.

I would also recommend that we add a column to the KM grid to flag if the KM is part of an upgrade or not. A blank value would indicate that the KM was "User Created".

Again, pardon my ignorance. Can someone tell me the difference between a key move created by KM/RM as part of a device upgrade (as a user convenience) and that same key move entered directly in IR by the user? In my mind, in either case, it's "part of" the corresponding upgrade... how it got into IR is irrelevant. Why would you auto-delete one and not the other?

Hmm..good point..can't answer that one

Additionally we can always add more sections for other information

Doesn't that go against the argument you guys have been giving me for my suggestion? Based on what you're saying here, if we want to add another piece of stored data for a key move, it will have to somehow be integrated into the appropriate entry in the [Key Moves] section, such as the UpgradeFlag, correct?

Not really. It's like the same comment above about the tables. Unique info goes under each appropriate section. As opposed to a section that contains all the info for a KM

I'm not trying to be argumentative here; I just want to see the proper format used (whatever it may be) if we're going to proceed with this. I'm just tying to think "down the road" as opposed to "here and now".

No problem. These are healthy discussions. This way we can come up with a format that everyone agrees to. I can code it either way. That is why I suggested that you could mock up a file as you would envision it.

Then we can poke holes in it

[Mark Pierson]

You are correct only the BoundDevice:BoundKey is the minimum for a KM identification. I believe Nils was thinking down the road when he suggested the rest. In fact that is how I had originally defined it.

I just can't see any benefit to such a convoluted key, especially when it's all redundant info. BoundDevice:BoundKey should suffice for key moves.

Correct me if I'm wrong, but doesn't IR already parse the key move hex from the [Buffer] section into the appropriate details? It must somehow, or how else does the Key Moves grid get populated, and how does it differentiate key moves from macros?

No problem. These are healthy discussions. This way we can come up with a format that everyone agrees to. I can code it either way. That is why I suggested that you could mock up a file as you would envision it.

Maybe a compromise could be multiple keys within the [Key Moves] section (a variation of my original suggestion)? For example, using the format:

BoundDevice:BoundKey:IniKeyName=value

That would give us

[Key Moves]
TV:TV/VCR:Note=This is a note
TV:TV/VCR:IniKey1=data goes here
TV:TV/VCR:IniKey2=more data goes here
CBL:1s:Note=This is another note
CBL:1s:IniKey1=data goes here
CBL:1s:IniKey2=more data goes here

In my simple mind, this approach gives the best future expandability. As new IniKeys are needed to support new features, they can just be added without changing the format of any exisiting keys or data.

While I'm at it, here's some suggestions for the other sections:

[Macros]
BoundKey:IniKeyName=value

[Devices] ***
BoundDevice:SetupCode:IniKeyName=value

[Protocols] ***
PID:IniKeyName=value

*** some thought needs to be given here since IR allows Devices and Protocols to be duplicated.

Then we can poke holes in it

Poke away! 8)

[e34m5]

I like you original idea better. Less code in IR...over night I think I figured out how to structure this in the code.

[KEYMOVES]
TV:TV/VCR
TV:Ph1
.
.
.
n

[TV:TV/VCR]
Notes: blah blah blah
Device:
Ugrade:
.
.
.
etc

As soon a we are fiished w/5.00 for sure, I'll start on this (5.01)

[Mark Pierson]

doesn't IR already parse the key move hex from the [Buffer] section into the appropriate details?

[KEYMOVES]
TV:TV/VCR
TV:Ph1
.
.
.
n

As I asked above, wouldn't this possibly be redundant and unnecessary info to store in and read from the file?

However, I'm starting to think my "multiple keys within a specific section" format would be better if/when IR gets ported to a non-Windows-specific platform. For example, I think Java can more easliy read and parse unique keys from an internal buffer (I forget what it's called... a "hash table" maybe?).

My understanding is that this is essentially how RM handles .rmdu files. If a key is there, it reads it.. if not, no harm done. And, it ignores [Section] headings (when KM was able to save in .rmdu format, the files had [Sections] solely for the HRF factor).

[e34m5]

doesn't IR already parse the key move hex from the [Buffer] section into the appropriate details?

That's one of the reasons I wondered why we needed more than just the notes in the file. Everything else is already in the buffer.

[Mark Pierson]

That's one of the reasons I wondered why we needed more than just the notes in the file.

For now, that's correct since Notes is all we're saving. But what about future details (like this so called UpgradeFlag) that we haven't even dreamed about yet? That's where unique keys make sense IMHO, because it's easier to add them than it is to redifine an exisiting one.

[e34m5]

Agreed...maybe I just need to make a file and let you guys look at it.

As soon as we complete 5.00.