Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000537OLVUser Interfacepublic2012-03-16 01:572012-07-31 17:45
ReporterFred 
Assigned ToBenFenner 
PrioritynormalSeverityminorReproducibilityN/A
StatusassignedResolutionopen 
PlatformAllOSAllOS VersionAll
Product Version0.0.3-SNAPSHOT 
Target VersionASAPFixed in Version 
Summary0000537: Separate Extension And Content Handling
DescriptionProvide 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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0001277)
Fred (administrator)
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.
User avatar (0001687)
BenFenner (developer)
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.

User avatar (0001688)
Fred (administrator)
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.
User avatar (0001690)
Fred (administrator)
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.
User avatar (0001691)
Fred (administrator)
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.
User avatar (0001692)
Fred (administrator)
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.
User avatar (0001694)
BenFenner (developer)
2012-07-21 18:28

*thumbs up*
User avatar (0001782)
BenFenner (developer)
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".



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker