[FLOW3-general] FLOW3 Background Service / Daemon

[Manuel Strausz]

Am 09.08.2010 21:15, schrieb Thomas Fritz:
> of SRM. I know that it is not that easy - but i definitely think that it can
> be done and would be a real killer! ;) An Application built on top of FLOW3
> would benefit from such a service or services especially on high load
> applications.

Hmm, yes for high load this would definitely be an improvement. The more 
I think about it the more I like it. Being able to strip away a big part 
of the boot process would definitely make things a lot more 'slick'.

> With the new HTML5 features like WebSockets or Server Sent Dom Events such a
> background service could be the base for a WebSockets Server for FLOW3.

Yes, it should be easy to provide interfaces to the outside world/HTML5 
for the various background services. It's almost a logical consequence.

> As i said above i think the CLI could also be started as such a backgrund
> process - optionally of course. I realized when i tried a patch from this
> issue http://forge.typo3.org/issues/4426 that there is already a background
> process for the CLI. The class for this whcih gets used is
> \F3\FLOW3\CLI\Host
> Here is the part how it gets used in Packages/FLOW3/Scripts/FLOW3CLI.php
> <code>
> do {
> $host->output('Enter command: ');
>   $input = $host->readLine();
> try {
> $host->parseInput($input);
>   } catch(\F3\FLOW3\CLI\Exception\InvalidInput $e) {
> $host->outputLine('Error: Could not find a matching command.');
>   $host->outputLine('Enter \'help\' to get a list of available commands.');
> } catch(\F3\FLOW3\CLI\Exception\MissingArgument $e) {
>   $host->outputLine('Error: Not all required arguments were specified.');
> $host->outputLine('Enter \'help\' to get a list of available commands.');
>   }
> } while(TRUE);
> </code>
>   As you can see it gets used in while loop and waits for user input. Once
> started it is really fast.


I see what you mean, it's also a lot less overhead when you don't have 
to bootstrap the framework everytime you call a CLI command.

Another usecase I just thought of where it would make a big difference 
is content-protected media output, e.g. images that should only be 
visible/downloadable when you are logged into the backend. If most of 
the framework is already loaded, you can dynamically generate the images 
from a controller and return them (or not, if you don't have 
permission). If the whole framework needs to be booted up first you'll 
notice a visible delay in every image tag, and this only gets worse with 
multiple images.

Would be interesting to hear what the core devs think of this idea. Did 
you open up an issue on the forge regarding this already?

Anyway, back to work. :)

kind regards,

Manuel