Dan,

I'm sorry did you say commitment?

That's it, I'm out of here...

Anyways, I am interested in participating in some of the things you were
speaking about, how do I become more involved.

Thanks,
Tim
;)

--------------------------------------------------
From: "Daniel Stenberg" <daniel_at_haxx.se>
Sent: Wednesday, August 19, 2009 3:40 AM
To: "the curl tool" <curl-users_at_cool.haxx.se>
Subject: Re: [PATCH] make non-blocking stdin optional

> On Tue, 18 Aug 2009, Eric Wong wrote:
>
>> My previous change to make stdin non-blocking by default for "-T-"
>> actually broke existing behavior for some applications. It could cause
>> the readbusy flag to be permanently set if the server doesn't send any
>> data while it is reading data from the client.
>>
>> This restores previous behavior for "-T-" to not touch the non-blocking
>> flag for stdin by default (the parent application can still set it, of
>> course).
>>
>> Making stdin non-blocking in curl is still possible by specifying "-T."
>> instead of "-T-". I chose '.' because it is an impossible name for a
>> regular file.
>
> Ok. Thanks for the fix. I've not heard anyone complain so quite clearly it
> hasn't at least hit a very large amount of (vocal) people. I too think "."
> is quite fine, even if I bet some systems _can_ use it as a file name.
>
> Can you please also add a little mention of this new way to the
> docs/curl.1 man page?
>
>> Has anybody investigated moving the tool over to use the multi interface
>> so we can poll stdin? I think that'll be a cleaner solution and will
>> help avoid freezes that can still happen right now with the non-blocking
>> stdin case.
>
> It's been mentioned in the TODO for ages and I would really like to see it
> happening. Some things that have prevented it from happening so far:
>
> A) My own time and effort in the curl tool. I'm much more focused on work
> in
> the libcurl side of our merry project, and even there I'm not keeping
> up
> with mail, bug reports and features. This makes me lag behind and even
> simply just not doing anything on the tool side of things. I'm hoping
> others will step up and fill in when the need comes. But it has slowed
> down
> the pace for adding of new things. Things like metalinker support died
> (or just stalled) because of my (personal) decision to basically not
> take
> on larger work in src/ right now.
>
> B) It easily opens up your mind for "oh if we're going multi interface
> then we
> can also add support for ..." and then fill in N number of crazy
> far-out
> ideas! ;-) The multi interface is perfect for multiple parallel
> downloads
> and more. Not that new features and coolness is bad, but it takes the
> little job into the next level of then having to be something that
> perhaps
> is a little more thought through and planned than otherwise.
>
> All this said, I am NOT against good suggestions or improving curl in
> every possible way. I will however be more picky on getting fine patches
> that need less manual work on my behalf, or even hand out CVS commit
> access to the brave heroes that are willing to take on the challenges.
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
> FAQ: http://curl.haxx.se/docs/faq.html
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-08-19