Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65857
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1331291088.20130215023506@cypressintegrated.com>
References: <511CEEB1.7040303@hoa-project.net>
	<511D5924.4070602@sugarcrm.com>
	<713003612.20130214164753@cypressintegrated.com>
	<CAEZPtU5pr8K5yJY+owKMDMX49aVY3N_eHuXaeqO4fiOiJCdzgg@mail.gmail.com>
	<1331291088.20130215023506@cypressintegrated.com>
Date: Fri, 15 Feb 2013 09:13:46 +0100
Message-ID: <CAEZPtU6AfAW=GuDay3ZNraesL65WD5hNYAbU8wyQDUpbRwfuOA@mail.gmail.com>
To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Cc: Pierre Joye <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] File system watcher/monitoring
From: pierre.php@gmail.com (Pierre Joye)

hi Sanford,

On Fri, Feb 15, 2013 at 8:35 AM, Sanford Whiteman
<swhitemanlistens-software@cypressintegrated.com> wrote:
>> There are native APIs for that (read: non .net, aka C) on Windows
>
> Well aware of that. The EXE does use the Win32 API, not a .NET
> wrapper. I've used that API ever since it's been documented.

Right, but these APIs can and should be used within the extension. I
have a couple private extensions using them.

>> using an external process for this purpose would be horrible, in all
>> possible ways.
>
> Well, yeah, that's my very point... having the engine/extension do
> this is the proper direction (I only use this hack to check completion
> of some scheduled tasks, it's all private).
>
> Stas says typical PHP apps don't have a need for file system hooks.

Well, I tend to slightly disagree with him here, that's something,
along with a better locking API and another for shared memory (shared,
process or thread) should be available.

> Sure, long-polling may not be good with thread-per-process webservers,
> but those aren't the only PHP environments in the wild. Once you
> accept that people already roll out long-polling back ends with PHP,
> the next step is to minimize the check-sleep-loop hackery and offer
> true event-driven alternatives when possible.

Events based APIs are already part of the PHP ecosystems. I see no
problem here, even within a request. However there are some technical
issues to solve, APIs and how they should work outside or between
requests.

> Nothing I'm saying is controversial.

That's a tech discussion, I do not see controversy here but exchange
of views or arguments, that's how we move forward :)

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org