Stephen Warren wrote: > 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 curious as to what you use to figure it out... there are some tells like firmware has '<TYPE>Firmware_Main</TYPE>' and '<NAME>Upgrading 880 Application firmware to version 4.0.13 (20050504_165503)</NAME>' but not all of them are so straight forward - did you just pick a unique option from each file? > I'm thinking about porting this to C for libconcord. I guess the API > would look like: libconcord is definitely the right place for it - I think I mentioned before I'd like to have that code in libconcord - I'm glad you'll be porting it. I'm sure you noticed that it's been on the TODO list since the beginning of time, so this means I don't have to write it from scratch! :) > #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); Looks good to me. Obviously we'll have to read in the file significantly earlier inside of concordance. I don't think that's a problem, but exactly where is interesting. We could do it in parse_options *if* we happen to be in auto_mode (where we currently do the filename matching stuff), but then we have to know if we've read it in or not and read it in later as necessary. That's sub-optimal. We can't read it in before we call parse_options, clearly, because we won't have the filename yet. So what I would suggest would be that parse_options no longer does any magic, and instead the code flow like this: parse_options - ONLY parses options, if MODE isn't set by an option, don't sweat it if no file name *and* no node, error read_file if no mode, call identity_file and then set_mode() based on that. In fact, we could even use the appropriate MODE_* defines as the filetype defines if we want (obviously we wouldn't use them all, just MODE_WRITE_* and MODE_LEARN_IR). > 1) Replace all read_*_from_file with a single API: Indeed, read_*_from are all but silly now, much less given this change. > Or in the future, we could just get the pointer via mmap, and all other > APIs wouldn't care. mmap(), it turns out, isn't cross-platform, so we'd have to do some #ifdef and use Windows calls in Windows land... but I *would* like to see is replace GetTag() with a light XML library one day. > 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. Given my above codeflow, I don't think anything will accept filenames anymore other than read_file. > 3) Update concordance (in auto mode) to always use read_file, then call > identify_file, then do the appropriate thing with it. See above. > 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. So as I've worked on the XS perl wrappers (finally got everything working tonight I think, now I'm just cleaning stuff up), I've been thinking about the API, and I'm starting to think more and more that all our uint8_t* and uint32_t* stuff really should just be a void* blob which is internally a structure with the uint8_t* and the size inside of it. Not only do I think of that array as a opaque blob to the user, but I don't want our API/ABI to have to change when we make it into an mmap pointer or some other thing. Thoughts? -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/concordance-devel
