> > why do you need events instead of the just recognising that the
> process has finished?
>
> Because the processes are not tightly coupled, nor all on the same
> server.
> One process may update data or recalculate inventory, and a separate
> process may then decide to run a report or push the changes onto another
> system. Putting them in one script would require the rules of various
> business units to be in the one script.
>
> A concrete example is a script would wait for an event caused by our
> Solomon server pushing data from its SQL Server backend into our
> Firebird inventory database.
>
> But this thread is starting to drift, I'm more interested in the how as
> we've already determined the why to our satisfaction.
>
> Rick DeBay

I apologise about the why questions - it was only out of interest really.
I am still puzzled by the choice of PHP here. My thoughts may clarify.

Scripting per se is meant for short lived execution. They are granted an
execution timeout which by default on many scripting setups (PHP, perl,
VBScript, JSctipt (Serverside) etc) is quite short - 90seconds. Long running
scripts (e.g. sending bulk email) require a substantial increase in timeout
which is also considered a security issue where scripts are easily placed
and executed by anonymous entities.
They are not tailored for desktop execution since once they are exectuted,
there are no user intervention mechanisms, no close button, no file exit
etc.
So to set an endless loop even with a lengthy timeout seems counter to the
whole logic of server scripts.
Your timeout would need to be controlled by the overall PHP.ini script
timeout I suppose. And you would need to live with the fact that where you
do not receive the event, do you act as if the timeout was received OR do
you assume that the event did not fire for some reason?
I would have thought that a running service would be a far better option for
such a task, or a running desktop application which has no timeout. Milan
Babuskov has alerted me to PHP-gtk - a wrapper for writing GUI apps in PHP.
Maybe... but as I said "just seems like a lot of work to make PHP walk and
talk like a duck". There are so many other ways of making a gui frontend
without learning yet another weird set of nuances ... my question is why?
even if you had miles of legacy script it still doesn't make a lot of sense
to me.
This is stated without knowledge as to whether events in PHP.Firebird are
doable.
I'm still to be convinced that PHP would be a good residence for use of FB
events.
Alan