3 suggestions: I honestly have no idea if this would work, but maybe fopen supports non-blocking connections? Or creation of context-based connections (for which you can use stream_set_blocking). If so, you could take a stamp of the current time plus a timeout value, make the fopen call (which would return immediately) then wait politely (I mean that from a CPU perspective) in a loop until you have data, or the current time goes past your time stamp. Another avenue for investigation might be to try file_get_contents to see if it's connection timeout can be controlled. It seems to work in a similar way to fopen, in terms of having wrappers that are aware of multiple resource types. It might also be worth taking a look at cURL or similar libraries that are also multi-resource aware, but give you greater control of connections parameters and timeouts. Geoff. On 19 Jan 2006 at 14:49, Richard Lynch wrote: > On Thu, January 19, 2006 5:17 am, Jochem Maas wrote: > > Richard Lynch wrote: > >> So I've been poring over the docs for the new stream stuff, and it > >> looks pretty nifty, except... > >> > >> I'd really like to be able to just hand a URL to PHP like: > >> http://php.net/manual/en/ref.stream.php > > > > er you can if allow_url_fopen ini setting is set to 1 (can't you?) > > > > $fh = fopen('http://php.net/'); > > The crucial point buried too far into my initial post (sorry): > > I NEED to specify a timeout for the initial CONNECTION to acquire the > data. > > fopen does not allow this. > > fsockopen does, but then I'm stuck with re-inventing the wheel on > handling dozens of different protocols to initiate the process to get > the data rolling. > > For HTTP, you have to send "GET $path HTTP/1.0\n" > For FTP, you have to send "GET $path\n" > For a file, you don't send anything > .. > .. > .. > > So to get all the functionality of fopen() I'd need a monster long > switch statement with a bunch of protocols about which I know almost > nothing, including some rather complex stuff I can guarantee is over > my head for ssl:// https:// ftps:// and friends. > > I really do not want to re-code all that, when I know it's down in the > guts of 'fopen' > > In other words, I need an additional 'timeout' argument to fopen() > that works when url_wrappers is on, or a function to set the default > timeout for fopen() to wait. > > PLEASE don't refer me to stream_set_timeout. THAT only applies to how > long to wait for data AFTER the stream is open and you are reading > data. > > I'm asking for: > > The convenience of fopen() that knows about dozens of protocols and > takes care of the grotty details so I can just start reading data. > > The power of fsockopen() that allows one to specify how long to wait > for a slow source feed. > > What I was hoping for, then, was that I could call this mythical > function url2context() that would convert *any* URL into an > appropriate stream context. > > Then I thought I would be able to use that contact for fsockopen() > with a timeout for connection. > > I now see that fsockopen() does not even take a stream_context, but > that fopen() now does, and none of this would do me any good at all... > > I guess I was thinking that the magic of fopen() being able to handle > all those protocols had been bundled into the streams code, and that I > ought to be able to utilize that somehow WITH a timeout on the > connection. > > I guess I'm stuck with re-coding all the stuff from fopen() in a giant > PHP switch and using my old-school fsockopen, just so I can have > control over connection timeout. :-( > > And it looks like all the new streams stuff is very nifty for some > things, but rather useless for the feature that I believe quite a few > users have been asking for: > > Gimme fopen() with control over timeout, so I can ignore all the > minutia of what kind of file/stream/URL/whatever I'm reading, but not > have my application waiting for 2 minutes when somebody else's server > goes down. > > I tried to open a "Feature Request" to this, but it's already been > closed as "Bogus" wherein I was told to rtfm. > > I've re-opened it, but based on my past mixed experience with the > people behind bugs.php.net, I figure I've only got a 50/50 chance of > somebody who actually reads and comprehends what I typed seeing it > before it gets closed again and ignored. :-( > > Don't get me wrong -- I know what a monumental task they face, and am > aware that there are certain Pavlovian automatic reactions, and that's > how it is when they see the keywords embedded in my Change Request, so > I'm not dis-ing them... It's just Reality that a worthy feature worth > considering is probably going to get buried in the Bogus pile. [shrug] > > If anybody reading this actually agrees with me, feel free to vote here: > http://bugs.php.net/bug.php?id=36072 > > If you think I'm an idiot, by all means vote against the feature request. > > -- > Like Music? > http://l-i-e.com/artists.htm > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > > !DSPAM:43d009866985315134984! > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
