In congruity, I have some code to identify the action to take for a specific EzHex/EZUp file, without relying on any facet of the filename.
I'm thinking about porting this to C for libconcord. I guess the API would look like: #define TYPE_CONNECTIVITY 0 #define TYPE_CONFIGURATION 1 #define TYPE_FIRMWARE 2 // returns some error if can't identify. int identify_file(uint8_t *in, uint32_t size, uint32_t * type); Now, the question is then: Where do we get in/size from? Right now, libconcord has separate APIs to read files of different specific types. It seems that (especially since they all simply call a common function now) we should make the following changes: 1) Replace all read_*_from_file with a single API: // no need for binmode param, since we just grab the whole content // in all cases int read_file(char *filename, uint8_t **out, uint32_t *size); Or in the future, we could just get the pointer via mmap, and all other APIs wouldn't care. 2) Update post_connect_test_success to accept in/size instead of filename, so apps that have used read_file already don't read the file twice. 3) Update concordance (in auto mode) to always use read_file, then call identify_file, then do the appropriate thing with it. Does this make sense? If so, I'll probably first simply work on writing identify_file with the API I described above, which should be pretty self-contained, then do the other API changes separately after that, to avoid merge conflicts. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
