On Wed, 29 Jan 2020, 7:42 pm Peter Bowyer,
wrote:
> On Tue, 28 Jan 2020 at 17:12, Rowan Tommins
> wrote:
>
> > I'd just like to point out that those two things are orthogonal: the fact
> > that Swoole is distributed as an extension is not the reason it's
> > incompatible with your existing code,
On Tue, 28 Jan 2020 at 17:12, Rowan Tommins wrote:
> I'd just like to point out that those two things are orthogonal: the fact
> that Swoole is distributed as an extension is not the reason it's
> incompatible with your existing code, and building a similar implementation
> into PHP under a diffe
On Tue, 28 Jan 2020 at 15:59, Peter Bowyer
wrote:
> An approach that avoids rewriting, like some form of
> built-in support in the language would be good for this alone.
>
I'd just like to point out that those two things are orthogonal: the fact
that Swoole is distributed as an extension is not
On Tue, 28 Jan 2020 at 14:26, Thomas Hruska wrote:
> People tend to write WebSocket servers in NodeJS partly because they
> don't realize that PHP can already do the same. Example:
>
> https://github.com/cubiclesoft/php-drc
I didn't realize, so this is a great share. Thanks.
> WebSocket gene
On 1/26/2020 2:31 PM, Rowan Tommins wrote:
On 25/01/2020 22:03, Mike Schinkel wrote:
I'm not following the discussion 100% – more like 85% — but it seems
like what we might be saying is the need for a user-land
implementation of a long-running PHP request, one that does not timeout?
It's not
On 27/01/2020 15:50, Larry Garfield wrote:
I want to point out that there's 2 or 3 very different use cases and
models being discussed in this thread, and it's important to keep them
separate:
[...]
Can I add another that's been mentioned in passing:
4. A mechanism for working with WebSocke
On Mon, Jan 27, 2020, at 8:19 AM, Robert Hickman wrote:
> > > I'm not sure that would work well for Web Sockets, because it still
> > relies on the traditional request-response cycle, but I've never really
> > used them, so don't know what kind of architectural patterns make sense for
> > them.
> >
> > I'm not sure that would work well for Web Sockets, because it still
> relies on the traditional request-response cycle, but I've never really
> used them, so don't know what kind of architectural patterns make sense for
> them.
>
> Considering the Swoole PHP extension (https://www.swoole.co.uk)
> On Jan 26, 2020, at 4:31 PM, Rowan Tommins wrote:
>
> It's not about timing out, as such, it's about starting with a fresh state
> each time a request comes in from the web server. So the long-running script
> can't just "opt out of time outs", it's got to be launched by something other
> th
On 25/01/2020 22:03, Mike Schinkel wrote:
I'm not following the discussion 100% – more like 85% — but it seems
like what we might be saying is the need for a user-land
implementation of a long-running PHP request, one that does not timeout?
It's not about timing out, as such, it's about star
> On Jan 25, 2020, at 5:35 PM, Dik Takken wrote:
>
> Go channels are about solving problems related to true concurrency:
> Multiple threads concurrently handling requests in a single shared
> memory environment. I think Robert is talking about sequential request
> handling in a single shared memo
On 25-01-2020 23:03, Mike Schinkel wrote:
> Then we could look to prior art with GoLang channels where they "Communicate
> to share memory" and do not "Share memory to communicate." IOW, add an API
> that allows a regular PHP page to communicate with a long-running page. This
> would decouple
On 24-01-2020 10:29, Robert Hickman wrote:
> PHP is pretty unusual in comparison to most web platforms nowadays as it
> runs each request in an isolated process. Web development in other
> languages is instead based around a long lived set of processes, which
> serve multiple requests.
The shared-
On Jan 25, 2020, at 3:44 PM, Rowan Tommins wrote:
>
> On 25/01/2020 18:51, Robert Hickman wrote:
>
>> Yes that is what I was thinking, for example there is a userspace
>> implementation
>> 'Swoole' that works in the following way, ReactPHP is similar although I
>> won't
>> include that example
On 25/01/2020 18:51, Robert Hickman wrote:
Yes that is what I was thinking, for example there is a userspace implementation
'Swoole' that works in the following way, ReactPHP is similar although I won't
include that example as well.
So trying to get concrete: the first "official" component we
Hi Rowan
> Could you share some more thoughts on what you are thinking of here? I'm
> guessing you're thinking along the lines of an "event-based" system,
> where each request is a function call, rather than a whole script
> invocation?
Yes that is what I was thinking, for example there is a user
On 24/01/2020 09:29, Robert Hickman wrote:
PHP is pretty unusual in comparison to most web platforms nowadays as it
runs each request in an isolated process. Web development in other
languages is instead based around a long lived set of processes, which
serve multiple requests.
That model has ad
PHP is pretty unusual in comparison to most web platforms nowadays as it
runs each request in an isolated process. Web development in other
languages is instead based around a long lived set of processes, which
serve multiple requests.
That model has advantages in that it is very easy to cache dat
18 matches
Mail list logo
