So, get directly to your questions: > > 1) Can we still integrate this functionality to existing class CURLFile?
I think it would be possible, because like @smalyshev said, CURLFile represents symbolic file, that is going to be uploaded with CURL. So my suggestion would be creating a static factory method on this class, something like `CURLFile::createFromBuffer( string )` or `CURLFile::loadFromBuffer( string )`, which would create a CURLFile object and initialize it with the passed contents („buffer“). 3) What do you think about unserialization for this class? > a) Do not accept it (becouse object can contain very big file) > b) Accept I am for (un)serialization for this class. I think it's upon its user to think whether to use it or not (because it could be a benefit, but there are also situations, when it's not -- like that case, in which you have very large file buffer). Best reagards, Kubo2 2015-04-18 23:35 GMT+02:00 Stanislav Malyshev <smalys...@gmail.com>: > Hi! > > > I have few questions for my pull request: > > https://github.com/php/php-src/pull/1217 > > > > Short story: in some special cases we need to upload just created small > > file(s) by CURL. For example it's autogenerated image or pdf. And libcurl > > give for us this options: CURLFORM_BUFFER, CURLFORM_BUFFERPTR and > > CURLFORM_BUFFERLENGTH. My request about adding this options to curl php > > extension. > > I wonder if it's be hard to make streams work there... Then you could > just pass php://memory or data:// as the file. Not sure about security > implications though, needs some thinking. > > > For basement I used class CURLFile, but can't find solution to use same > > class, because this class require file name on disc parameter in > > constructor. So I created new class, now it called as CURLBufferFile. > > While it does require file name as parameter, nobody says anything about > disc there. So in addition to the above, you just could add > setFileContents() API (or setFileBuffer? feel free to bikeshed :) that > would make it take existing buffer instead of reading the file. > > > So, my questions are: > > 1) Can we still integrate this functionality to exists class CURLFile? > > I think, yes. Or at least we should try to. The meaning of CURLFile is > not "file on disk", it's "something to be fed to CURL to be uploaded as > a file", so having buffer does not violate the semantics. > > > 3) What do you think about unserialization for this class? > > a) Do not accept it (becouse object can contain very big file) > > b) Accept > > I don't see big issue in serializing/unserializing it. Yes, it can be > big. So can be any string you can pass to unserializer, any object can > contain tons of data, nothing different here. This object is just > container for its values, so I don't see anything special here. > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
