Re: [PHP] Persistent flag in memory

On Thu, Feb 11, 2010 at 8:47 AM, Teus Benschop <[email protected]> wrote:
> On Thu, 2010-02-11 at 08:26 +0000, Jochem Maas wrote:
>> if you're doing all this already in order to facilitate a multi-platform
>> install ... why not go the extra yard and have the install process setup
>> a cronjob (or scheduled task, launchd entry, etc, depending on platform)?
>
> The reason is that the php application will not only be installed
> locally, but also properly on a server. And some users could have
> servers that do not offer access to the cron daemon. Which means it
> might be covered by the installer on windows, and other platforms, but
> there would still be no crontab equivalent on the server that runs on
> the internet. Hence an platform-independent solution is still needed.
> Once that platform-independent solution is there, it could as well be
> deployed everywhere. But this seems to be going off-topic.
>
>> I have recently been using daemontools (*nix/bsd compatible daemon management
>> tools ... also used to manage qmail processes) to actually keep a
>> long running / perpetual script running ... it's a very robust bit of
>
> If little or no configuration would be required that would help, and if
> it were available on commodity servers like Bravehost that would be a
> plus too.
>
>
>> it's merely the vehicle your using to have the script run
>> perpetually that irks me.
>
> Well, on the type of vehicle used to get a job done, my feeling is that
> PHP is very flexible and should / can adapt to the user's need, so why
> not use the tools provided?
>
>>
>> in practice not much on a personal machine - nonetheless it's wasteful
>> and technically a webserver is unneeded and creates another layer of
>> complexity and overhead. it does seem rather brittle in terms of how you
>> have it set up though.
>
> Basically it is written as a web application, which installs locally as
> well. Therefore to reduce programming efforts, and to make it easier to
> be cross-platform, the LAMP server was chosen. Programmer's efforts are
> expensive, therefore choosing these robust tools as Apache, MySQL and
> PHP / Perl / Python was done for that reason.
>
>>
>> it's possible that it's the best you can do given the pratical circumstances
>> of the users/maintainers of the installations ... but I hazard to say
>> you 'wrapper' for you perpetual/reaccuring script *might* be a sub-optimal
>> setup ... then again it's rather hard to say without known exactly what you
>> want done every minute, why it needs to be done on the user's machine and
>> what the connection with a cloud.
>
> The "cloud" comes in when somebody installs  the app in such an
> environment (if that is at all possible, I haven't looked into that).
> The tasks to be done every minute is to check incoming email and process
> is since users can operate the system through email as well must like a
> message board where users can post by email. Then there's the processing
> of the outgoing email queue since all "email" sent to a user is first
> going to be put online, then transferred to email if the connection is
> on. Then there would be regular tasks as sending out diffs to the users
> since this is an online collaboration environment for translators, so
> other members can see who changed what in the translation. (This all is
> still to be made, but these are the plans). PHP is very flexible so
> should be able to do all of this. But I am afraid to go off-topic again.
>
> Teus.
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Could the app be converted to an Adobe AIR app or use PHPdock (
http://www.nusphere.com/products/phpdock.htm ) to run local? There are
a number of security issues that surround installing a webserver and a
database locally on a users machine that may become issues.

-- 

Bastien

Cat, the other other white meat