This extension does not belongs in PECL. It is fully platform
compatible, all other languages offer this functionality, it is actively
maintained (by me), and it will be marked stable by version 4.3
-Jason
n Mon, 2002-09-09 at 18:13, Shane Caraveo wrote:
> Dan Kalowsky wrote:
> > Because the us
Dan Kalowsky wrote:
> Because the user can see how active such functionality is by looking at
> the CVS logs, and doing a search on php-dev conversations.
Sorry, but that's a copout. It expects way to much of the user. If
it's going to remain experimental, OR the api is going to continue to
c
Dan Kalowsky writes:
> Not to continue a "flame war", but this is Open Source, and it is
> done on free time.
"Open Source" is a philosophy.
It shouldn't be an excuse.
Nothing prevents us from treating people with patience and courtesy.
Except of course bad manners and bad attitude.
> Because
and benefit no one.
--Roshan
> -Original Message-
> From: Dan Kalowsky [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 09, 2002 2:49 PM
> To: NAIK,ROSHAN (HP-Cupertino,ex1)
> Cc: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] sockets extension
>
>
> B
Because the user can see how active such functionality is by looking at
the CVS logs, and doing a search on php-dev conversations.
While the authors have decided to mark it experimental doesn't mean it
will ever not be experimental.
Not to continue a "flame war", but this is Open Source, and it
>
> Between 15 days and 15 months.
Looking at the CVS its been 19 months since the EXPERMENTAL file was last
modified for sockets.
No offense intended but, sometimes people dont seem to like to be asked such
"obvious" questions by users. I realize that people in open source are not
working for
On Mon, 9 Sep 2002, NAIK,ROSHAN (HP-Cupertino,ex1) wrote:
>
> And exactly how long is it expected to continue to stay EXPERIMENTAL ?
Between 15 days and 15 months.
Derick
---
Did I help you? http://www.derickrethans.
And exactly how long is it expected to continue to stay EXPERIMENTAL ?
--Roshan
> -Original Message-
> From: Wez Furlong [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 06, 2002 3:31 PM
> To: Brian Lalor
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV]
Which part of "EXPERIMENTAL" in the docs at
http://www.php.net/manual/en/function.socket-select.php
don't you understand?
If you're so desparate to have things cemented, write a patch,
post it here and we'll commit it.
If you don't have the skills, you might consider offering those that
do some p
On Mon, 2002-04-29 at 11:14, Steve Meyers wrote:
> On Sun, 2002-04-28 at 22:43, Jason Greene wrote:
> > In the case of a socket you are selecting on has errored, the socket
> > will show up as readable. You then can perform a socket_read/recv, and
> > you should receive NULL (errored socket), then
On Sun, 2002-04-28 at 22:43, Jason Greene wrote:
> In the case of a socket you are selecting on has errored, the socket
> will show up as readable. You then can perform a socket_read/recv, and
> you should receive NULL (errored socket), then you can call
> socket_last_error to receive the errno.
>
Actually, I just reread your response again.
socket_select returns NULL on a SELECT error, this does not mean that it
will return an error on a socket IN the set you are selecting on that
has errored.
In the case of a socket you are selecting on has errored, the socket
will show up as readable.
True,
Threading support would be a powerful feature to php, but it is not
likely to happen anytime soon, due to current design issues with doing
it, and the fact that it would take someone who was really really
focused on adding this functionality (it would be alot of work).
Now with that said,
On Sun, 2002-04-28 at 18:31, J Smith wrote:
>
> One way to find which socket has died, if any, is to loop through each
> socket in the three sets (read/write/exceptions) and do a select() on each
> one to see if you can read with a timeout of 0. (The bad one being the one
> where select() retu
I was hoping on tagging this extension as stable by the next PHP
release. In order to do this, everyone needs to feel comfortable with
the extension.
Thanks,
-Jason
On Thu, 2002-04-25 at 12:46, Michael Virnstein wrote:
> Hi,
>
> as i could read in the manual, the socket functions are completely
One way to find which socket has died, if any, is to loop through each
socket in the three sets (read/write/exceptions) and do a select() on each
one to see if you can read with a timeout of 0. (The bad one being the one
where select() returns -1, I think.)
J
Steve Meyers wrote:
> There's
You can kind of simulate multithreading with the sockets extension by using
socket_select(). Technically, the result is multiplexing and not
multithreading, but in the end, it works quite nicely -- you can handle
multiple incoming/outgoing connections without the need for forking or
multiple
Threading on the level you are talking about is unlikely to happen (search
the archives!).
If what you are writing is criticial enough to need multi-threading over
multi-processing, you are probably using the wrong language :-)
BTW: Under linux, fork() is cheap and there is not much difference b
There's only one thing it's missing -- the equivalent of
socket_get_status(), which is not part of the extension, despite the name.
If I set my socket to nonblocking, the only way to tell if it has died is
to try to write to it, which isn't always a desirable thing to do :)
Unless there's ano
The only feature which would be useful towards this module is threading. If
PHP were able to thread it could handle multiple incoming sockets and
neglegate the need for IPC between child processes (where PCNTL has been
used) as it could all be handled by a common parent with shared (not
copied) va
I've been using it since the first API revision and it's been working fine
for me. (Up to and including the latest API revision.) As far as I'm
concerned, it's getting pretty close to losing the experimental tag.
(Perhaps by PHP 4.3.x or so, barring any glarring problems that I've not
encount
Hi,
Simple when enough people have tested it and it reaches the
consensus that it's mature enough for being called stable
(api doesn't change anymore, more testers, you name it).
- Markus
On Thu, Apr 25, 2002 at 07:46:30PM +0200, Michael Virnstein wrote :
> Hi,
>
> as i co
Uhhh nevermind. I just grabbed 4.2.0RC2 and found that
a slew of fixes have already been commited.
-e
Eric Liedtke wrote:
>Oops forgot the message body on the last one
>
>Ok so after sleeping on it I don't think my solution was
>totally in line with the beauty and simplicity of php, I
>expec
Oops forgot the message body on the last one
Ok so after sleeping on it I don't think my solution was
totally in line with the beauty and simplicity of php, I
expect you should be able to pass either a hostname
or a valid ip in the addr arg. Anyway the other part
that confused me is that in t
Eric Liedtke wrote:
> I'm new in town here, so to speak, so I'm not sure about
> proper protocol here, but I found,what I feel is a problem
> in the socket extension code. Specifically in the socket_bind
> function. I was working with a friends code and it was
> trying to bind to port 80, howe
On Thu, 2002-02-21 at 01:40, Derick Rethans wrote:
> Hey Jason,
>
> On 20 Feb 2002, Jason Greene wrote:
>
> > Instead of just committing a gigantic patch to solve these problems, and
> > redefine the extensions behavior, I decided to open a thread for
> > discussion on how I intend to solve all
Hey Jason,
On 20 Feb 2002, Jason Greene wrote:
> Instead of just committing a gigantic patch to solve these problems, and
> redefine the extensions behavior, I decided to open a thread for
> discussion on how I intend to solve all the problems.
>
> My solution does involve modifying pieces of th
On Sun, Dec 09, 2001 at 04:17:57PM -0500, benjamin yates wrote:
> > > The problem with the zip file he sent is also that a:
> > > ]$ diff -uN orig new
> > >
> > > produces a unified diff with almost all of it being whitespace
> > > related, so its near impossible to view the change
> > The problem with the zip file he sent is also that a:
> > ]$ diff -uN orig new
> >
> > produces a unified diff with almost all of it being whitespace
> > related, so its near impossible to view the changes...
>
> that's what i did;-)
hmmm i think it's more a cr/lf thing.
On Sun, Dec 09, 2001 at 07:42:46PM +0100, Sterling Hughes wrote:
> >
> > please send a unified diff.
> >
> > i'll look at integrating your changes then!
> >
>
> The problem with the zip file he sent is also that a:
>
> ]$ diff -uN orig new
>
> produces a unified diff
>
> please send a unified diff.
>
> i'll look at integrating your changes then!
>
The problem with the zip file he sent is also that a:
]$ diff -uN orig new
produces a unified diff with almost all of it being whitespace
related, so its near impossible to view the
please send a unified diff.
i'll look at integrating your changes then!
tc
On Sat, Dec 08, 2001 at 08:20:56PM -0500, benjamin yates wrote:
>
> hey all... i've been using the sockets extension pretty extensively for
> the past couple months, and it has some real problems. ob
re not complete because of
the 128bytes limited fgets
and there PHP hangs, browser keep waiting for the end of the page ...
what troubles did you have with 4.0.6 and how did you fix it ?
Thanks again
Arnauld
- Original Message -
From: "Leo" <[EMAIL PROTECTED]>
To: "
On Thursday 26 July 2001 18:06, Arnauld Dravet - smurfie wrote:
>
> Then i tried that:
> $sock_tab = socket_get_status($sock);
> if ($sock_tab["unread_bytes"] >= 0)
> {
>$a_lire = true;
>while ($a_lire)
>{
> $bytes_left = $sock_tab["unread_bytes"];
> print("Reading from the s
On Wed, Jul 25, 2001 at 11:32:24PM +0200, Markus Fischer wrote :
> On Wed, Jul 25, 2001 at 03:20:35PM -0400, colin mcdonald wrote :
> > Are the php socket functions still as experimental as indicated in the
> > manual?
>
> They are still experimental and function names/parameter orders
> is st
On Wed, Jul 25, 2001 at 03:20:35PM -0400, colin mcdonald wrote :
> Are the php socket functions still as experimental as indicated in the
> manual?
They are still experimental and function names/parameter orders
is still subject to change.
Recently there was also a thread about some possible u
Stig Venaas wrote:
> On Thu, May 17, 2001 at 01:48:06AM -0400, Sterling Hughes wrote:
>
>>Well, it probably could be done anyway (abstract it another step).
>>However, I don't see it really being that beneficial. The socket
>>functions provide *low level* access to the system socket features.
On Thu, May 17, 2001 at 01:48:06AM -0400, Sterling Hughes wrote:
> Well, it probably could be done anyway (abstract it another step).
> However, I don't see it really being that beneficial. The socket
> functions provide *low level* access to the system socket features.
> There's no real point
Daniel Beulshausen wrote:
> At 21:23 16.05.2001 +0100, Wez Furlong wrote:
>
>> I'm not sure that the sockets extension would benefit from php_streams as
>> much as php_streams would benefit from the sockets extension, if you see
>> what I mean.
>>
>> I would like to see it using php_streams, as
At 21:23 16.05.2001 +0100, Wez Furlong wrote:
>I'm not sure that the sockets extension would benefit from php_streams as
>much as php_streams would benefit from the sockets extension, if you see
>what I mean.
>
>I would like to see it using php_streams, as that would result in PHP being
>much more
At 10:34 PM 5/16/2001 +0200, Daniel Beulshausen wrote:
>At 22:49 16.05.2001 +0300, Andi Gutmans wrote:
>>Daniel,
>>
>>Would it make sense to try to integrate the new php_streams into this
>>extension?
>>It might give php_streams a push and I'm sure Wez would work with you
>>fixing any remaining
I don't appear to have seen/received the rest of this thread,
so please pardon any mistakes in advance...
On 2001-05-16 20:49:30, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> Would it make sense to try to integrate the new php_streams into this
> extension?
> It might give php_streams a push and
At 22:49 16.05.2001 +0300, Andi Gutmans wrote:
>Daniel,
>
>Would it make sense to try to integrate the new php_streams into this
>extension?
>It might give php_streams a push and I'm sure Wez would work with you
>fixing any remaining issues.
>It would be a nice test bed.
>What do you think?
>
>A
At 04:01 16.05.2001 -0400, Sterling Hughes wrote:
>I've been meaning for a while to do this, so yes, that's perfectly ok.
>
>I don't quite understand "the return values of most functions had to be
>changed because win32 has a completely different error handling". Can you
>elaborate a bit more.
At 22:49 16.05.2001 +0300, Andi Gutmans wrote:
>Daniel,
>
>Would it make sense to try to integrate the new php_streams into this
>extension?
>It might give php_streams a push and I'm sure Wez would work with you
>fixing any remaining issues.
>It would be a nice test bed.
>What do you think?
tha
Daniel Beulshausen wrote:
>
>
> hi,
>
> i've updated the sockets extension so that it's usable under win32 as
> well, however it's incompatible to the "old extension" for some reasons
> (thats why i want some feedback):
> sockets fd under win32 are usigned, the previous approach of returning
Daniel,
Would it make sense to try to integrate the new php_streams into this
extension?
It might give php_streams a push and I'm sure Wez would work with you
fixing any remaining issues.
It would be a nice test bed.
What do you think?
About backwards compatibility, without having read the cod
47 matches
Mail list logo
