Am 16.04.2012 22:59, schrieb Daniel Stenberg: > On Mon, 16 Apr 2012, Marc Hoersken wrote: > >>> 5 - On many places in the code you use the hardcoded numers 4096 and >>> 2048. >>> Why those numbers? And why not use defined names for them? >> >> There is basically no reason for these specific numbers. 4096 is the >> initial read buffer size and 2048 is the increase/decrease step size. >> I could certainly use defines for those, but in reality it might be >> even better to remove them and find a way to figure out how many data >> actually needs to be stored. I am currently freeing unneeded space >> after the read process finishes, but there might be a better solution. > > I see and I appreciate your intensions. But until you (or someone > else) figure that out, I still think replacing the hardcoded numbers > with the use defined names is a better idea. That will also make it > easier for volunteers to experiment with different sizes at will and > better understand if all the occurances of the numbers have the same > meaning or not. Sure, that's correct. I will replace the hardcoded numbers with defined names. > >> I am fine with sending you everything as a series for patches, sure. >> Squashing individual commits also makes sense, but generally speaking >> I must say that I am not really a fan of rewriting the history of a >> published git repository. > > Please note that I didn't not ask you to rewrite the history of your > published git repository - that is an insane idea. You can easily > squash the commit series into a more limited series in a non-published > branch and then send us that patch series for merging. Although I feel > I should also repeat: I'm not saying this needs to be done as I > haven't actually seen the need, I'm leaving that to your descretion. > Having a somewhat clean commit series post to the mailing list will > also make all the changes much easier to review. > > And please, it is much better and easier if you work on providing > small and clean patches for us to merge one by one rather than that > you continue to work and improve your code in your own branch. It will > risk making the merge and review work harder. You can then merge with > our master and continue working on fixing things from there. Ok, I completely understand. I will try to cleanup the code changes and patches in order to merge early.
As I already said on Twitter: I will have more time for libcurl development after my thesis is done, roughly two weeks from now. ;-) Best regards, Marc ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
