Stephen Warren wrote:
>> 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.Definitely copy. >> 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 the reason I ask is that if you want the whole XML bit, any program can open a file and read it. Your specific case example that convinced me was "someone creates a blob in a client application and wants to hand it us for writing to remote." This would, I suspect, have no XML - nor would it need/want XML. Because if this client application made the blob, then the website isn't involved so there's no website metadata to have in the XML. Hence I thought of import_blob() and export_blob() simply being for binary data. > 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. That's true. It's a library for taking files from Logitech and writing them to a remote. The internal datastructures we use in the meantime I don't think the user should have to be bothered with. > Tieing these two parts of the API so tightly together seems to break > modularity to me. I'm not sure I see that... > 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. Hmm. Given the way they store binary data, that's true. It's either HEX-encoded in chunks, or in a big blob at the end, so ... yeah. > 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. Think about it the other way - why should an application have to bother with keeping track if the size of these blobs it really doesn't care about? It's quite silly, I think. I should just have a pointer to the internal representation of the file or files I care about. In fact, the only reason you get anything back at all is simply so you could potentially be keeping track of more than one file at a time, otherwise I'd just keep it all internal - init_concord() would initialize a data ptr and size and be done with it. I think it makes the API more cumbersome for the average simple use-case. However, you pointed out there's a more advanced use-case, which is why I had suggested an import_blob and export_blob. Though I should point out, I'm not necessary set on anything at this point. This discussion is really useful, and it continues to make me re-think it all. -- 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 concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
