Stephen Warren wrote: > Well, it is true that internally the library knows this. However, I > don't see a reason the application shouldn't be "allowed" to know this > information too; perhaps the application wants to copy the data or save > into some application specific buffer. For this reason, I think we > should expose length here too (and check it ==FIRMWARE_SIZE when passed > back in for safety.)
I'm not sure I agree. We already provide a way of saving this data: write_firmware_to_file() and write_safemode_to_file(). That array is simply an opaque data object to the library. I want to be able to change it without breaking the API, and if possible, the ABI. The user shouldn't touch it. Heck, they don't even need to know it's an array - it's just a pointer to them. With the config blobs, it's variable size, so we *have* to give them a size so they can give us a back size... but this still should be treated a lot like an opaque object. There's nothing to say they couldn't read several different configs and then want different things done with them, so there could be different sizes... but this isn't the case with firmware. No matter how many you got, it's always the same size. In fact, if I recall correctly, you have to erase and write FIRMWARE_SIZE when you do the update even if the code doesn't take that much space - the firmware blobs are padded. > For the Z-Wave remotes (or whatever remotes the website sends back .zip > files in Kevin's package of downloads/dumps) it looks like there are > multiple update/firmware blobs in a single package, so there won't > always be a single FIRMWARE_SIZE in a given session... We're quite a ways away from getting very far with those, and if we need to change the API for them, so be it... but changing it now in anticipation of code that we have not written and have no idea what it may look like doesn't seem very useful to me. > Well, I'm pretty sure mmap() itself doesn't exist on Windows for > example. Now, it's true that the same functionality is available, but > the API is named something different (CreateFileMapping/MapViewOfFile > for mmap and UnMapViewOfFile/CloseHandle for munmap according to a quick > perusal of MSDN) Gah, why can't they just implement basic posix syscalls? Life would get so much easier for everyone. I'm starting to understand now why companies who have Windows clients don't want to port it to Linux, it's way more work then it logically should be. At least it's #ifdef WIN32 ... #else ... #endif and not 400 different code chunks. (BTW, is your python GUI cross platform?) -- 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
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
