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
17 matches
Mail list logo
