On Wed, 21 Sep 2016, Gilles Vollant wrote:
I tried the "binary" option you suggested, and this not perform well. Only the base64 option does the job.
That's crazy talk! Of course you'd need to change some code to make libcurl handle such a binary input as I suggested could be a cool way to do it. You can't add support for files provided from memory base64 encoded either without changing code.
When changing code and providing new features, I think we should go for the best and most useful approach given the circumstances.
My experience with people asking for support for in-memory objects instead of external files, is that they usually ask for that because either they A) don't have a file system at all or B) they don't want to have any external files to their application or C) they already have that data in their program's memory anyway.
In exactly none of those cases does it make sense for the program to base64 encode the binary data (which can be huge in some cases) and pass that to libcurl, only to have libcurl strdup() that data and then decode it to binary again.
Also, with my suggested approach the code could automatically detect when such input was given and it would not be possible to confuse with an actual file name. With base64 encoded input, we'd need to invent a prefix that a file name couldn't have, so you couldn't even just use a plain base64 encoded area either.
Base64 is, pehaps, also more easy for user of libcurl using other langage than C or C++ and binding.
libcurl bindings have glue code to make their environments adapt to the libcurl API and if bindings would want base64 encoded blobs, they can easily do that. But I doubt they will. For bindings, I would say it makes much more sense for them to be able to keep such data in their ordinary variables and pass such a variable on when setting options and then I suspect it is more likely that the data is actually already there in a plain binary area somewhere that the binding glue can figure out and pass to libcurl.
I think the maintainer of curl must choose between a base64 approach, with less modification on curl code, or a binary approach, which need modification on url.c (by example)
Again, we need to modify source code anyway and there's no existing code that uses this feature so we should make the new feature as good as possible while making sure we don't break existing code using these options.
My suggested approach would be a generic how-to-send-binary-data-to-options-that-accept-file-names, and this option would then be the first one to use it.
I am the maintainer of curl, but I much rather have us discuss solutions and come to an agreement we both/all think is good.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
