Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Phil Dibowitz wrote:
>>> What about passing around a void* like I suggested with the size and all
>>> hidden inside of but an export_blob() API that dumps it to something easy -
>>> such as our uint8_t* with a size, and of course an import_blob() to go with?
>>> Initially this will be kinda of silly because the internal representation
>>> will be identical, but it gives us the freedom to change at will and the
>>> flexibility to let users hack on stuff.
> Why would we need to know which API created it? The whole reason for having
> an import/export mechanism is so that the blob is always the same.
>
> Hmm - OK, well if it was mmap()d, we'd have to close the file descriptor,
> but that's easy enough: if (blob->fd) {...}
Yes. Also, would import_blob copy, or reference the data? This might
influence whether delete_blob needs to free/delete[] the pointer.
> I see the API keeping closer to its current naming conventions:
Yes, I just used long names to make the purpose clearer in the email.
> Hmmm. Yeah, I guess. Do we still pass around binary flags then?
> Yes, I guess we do. But originally I had envisioned export_blob() and
> import_blob() to operate entirely in binary mode. Would there be any
> reason for them not to? If so, would we then need the extract_*()
> functions then?
Well, data/size contain either XML or binary right now. Maybe the blob
would contain the flag, set by saving a parameter passed to read_file or
import_blob? If the blob doesn't, then the functions would need still
need the parameter...
I guess overall, I'm still not totally sure I like the idea of hiding
the data behind a void*/struct/...
The main problem I have with this is that it totally ties the remote IO
functions, such as write_firmware_to_remote, to the file
IO/identification/... and parsing functions.
I see these as two completely separate sub-parts of libconcord; the file
IO and parsing functions just happen to generate data that is then
handled by the remote IO functions.
Tieing these two parts of the API so tightly together seems to break
modularity to me.
I'm also not sure that switching to any more advanced XML library would
actually require any form of data hiding or API changes; the XML library
would parse a byte-stream containing XML just like we do right now, and
the result of the parsing would still be a byte-stream that's processed
by e.g. write_firmware_to_remote. I figure all details of any XML
libraries that are used to do this would be totally hidden within e.g.
extract_firmware; I don't think there's any state that would need to be
passed between functions.
If we can't trust the application to pass a ptr/size from the parsing
function to the firmware writing function, then I don't see how we could
trust it to pass just a ptr either; either in the case of a simply buggy
or a deliberately malicious application.
-------------------------------------------------------------------------
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
