FreeEMS Issues - OLV
View Issue Details
0000537OLVUser Interfacepublic2012-03-16 01:572012-07-31 17:45
0000537: Separate Extension And Content Handling
Provide an override check box or radiobutton set or something in the file open dialogue such that you can open a .csv as a FreeEMS binary log, or vice versa. The main one is .log which could mean ****ing near anything legitimately. Currently it's a pain when people name them "wrongly" and it would be good if I didn't have to care.

This would mean that the type of decoder created would depend on a slightly more complicated rule set than "which filter/extension" which it currently uses.
No tags attached.

2012-03-16 01:58   
Target left blank once again. I suspect that you'll have some strong opinions on this, so we'll hash them out in IRC next time you've got some free time to do that.
2012-07-21 15:46   
(edited on: 2012-11-29 15:58)
Seeing this for the first time now too. I've come across this issue before too. In my opinion the file extension is not the only thing you want to use to figure out what type of file you're dealing with. If a file extension is "wrong" but the data matches one of the other formats we support the program should be able to figure that out. Ideally with no human intervention.

Putting this as 0.0.3 too.

2012-07-21 17:12   
Agreed, FreeEMS bin logs are guaranteed to hold 0xAA and 0xCC bytes. These map to a couple of odd rarely used symbols in the 256 char ascii set. We need an API per decoder:

isParsable(byte[] sample) which returns true if it thinks it can handle the file. It can be up to the decoder to handle the impl. Sample can be say 1k of data, or less if the file is tiny.

Pull the sample from the file, send it to each available decoder, collate the results, if only one accepts, use it, if more than one accept, ask the user which.

So FreeEMS would search for at least one 0xAA, 0xCC pair in the sample, and true if found. CSV would look for some valid header/values structure, and return true for that. Mostly it would just work.

Additionally, we should be able to force use of a specific decoder with some option/check box/etc.
2012-07-21 17:35   
Just realised that it should be a shade over 2*2k to guarantee a recognition. Also, just to clarify: a single pair of 0xAA, 0xCC (with stuff in between) corresponds to a parsable packet. Mike suggested 0xCC,0xAA back to back, but this fails to handle noise inserted between packets.
2012-07-21 17:39   
Wrong again, double double 2k, so over 8k, let's call it 10k, or whatever is available if the file is less than that big.
2012-07-21 17:40   
Or just give it the file, and not make an arbitrary size limit. Leave it up to the decoder impl of "isParsable" to decide how much it wants/needs.
2012-07-21 18:28   
*thumbs up*
2012-07-31 17:41   
(edited on: 2012-11-29 15:59)
This requires work on the decoders, so it is moving from target of "0.0.3" to "ASAP".