|
|
Posted by "Geoff" on 01/20/06 00:08
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!
>
Navigation:
[Reply to this message]
|