The Chronicles of Stuffed Guys

An interesting post by Jeff Moore about how web applications installation could be simplified:

Drag and Drop Web Applications
I think a drag and drop PHP web application should meet the following criteria:

• Make no requirements for PHP_INI_SYSTEM or PHP_INI_PERDIR configuration.
• Make no requirements for .htaccess configuration
• Work with default application level configuration
• Not require writable filesystem permissions
• Not require installing external software
• Not require unarchiving (a wish, i know)
• Not require obscure PHP modules

I was toying with a Perl self extracting CGI archive long time ago. I was doing this with a colleague. We actually managed to create a working prototype that was able to pack an application inside one CGI file, this file could be run later from a browser, it asked several questions about database parameters and then unpacked everything contained inside of it to proper directories.

I’ve also seen several other implementations of the same idea, even in PHP. In Perl with have a special “__END__” mark that we can place inside a file to tell Perl that this is the end of the code. Perl will also allow us to access everything after the __END__ just as a normal file, so we could do all sort of things that we do with normal files (open, read, etc). In PHP we don’t have __END__, but still the same could be achieved. For example, by enclosing the archive inside a very long comment in a PHP script. It might be required to encode the binary data in the archive as a string (using base64 encoding, for example). So in PHP this is also possible. And we actually considered creating a special installation system for our upcoming products that will be able to pack the whole product in one file and then interactively extract and install it.

But we’ve found out several complications in the concept itself:

1. Most of PHP web applications have an open source and it is a standard today that a power user of the product could tweak its code easily to match his needs. If we distribute only a self-extracting archive a user would have to first install the product on the server through a web browser and only then he will be able to download the code on his local machine to play with it. Not convenient.
2. PHP scripts are normally run with the server access rights, because PHP itself is usually installed as a server module. This means that if we will try to extract our product from an archive with a script that is accessed through the browser (as opposed to the shell) we a) might not be able to create directories and files at all on the server, because we won’t have enough rights or b) we might be able to extract everything, but all of the extracted files will belong to the server user — this means that any other PHP script on the same server could easily access them and do something bad. Not good too.

So, considering the above, the self-extracting PHP archive could only be offered as an alternative to a standard distribution (a zip file, that should be unzipped first, then uploaded to the server, then an installation script on the server is launched).

This appears to be a costly alternative (without a ready-to-use solution we will have to create such installer ourselves) and I am not sure right now if it is worth the trouble.