Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender)
Date: Thu, 14 Feb 2013 16:47:53 -0500
Reply-To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Message-ID: <713003612.20130214164753@cypressintegrated.com>
To: Stas Malyshev <internals@lists.php.net>
In-Reply-To: <511D5924.4070602@sugarcrm.com>
References: <511CEEB1.7040303@hoa-project.net> <511D5924.4070602@sugarcrm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-From: swhitemanlistens-software@cypressintegrated.com
Subject: Re: [PHP-DEV] File system watcher/monitoring
From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman)

> I think it'd be great to have a library with unified interface and an
> extension that uses it. However, I'm not sure if these libraries are
> useful in common php use case - short-lived requests. Could I get the
> changes since the last request? Or is it useful only for long-running
> persistent processes?

You're right of course that you are implicitly lengthening a request.
But if you are already embracing a long-polling model that waits for
filesystem changes, the back-end service can actually use fs events
instead of looping -- much more efficient. In fact I do this already
on Windows by running an external FileSystemWatcher EXE and waiting
for it to return (+ a timeout in the wrapper).

-- S.