Installing Web Applications
November 24th, 2004Mac OS X has made an art of the process of installing an application on the desktop. For a properly packaged application, the process is:
- Download.
- Locate the application icon in your download directory and optionally move it to another location.
- Double click on the application icon to run.
This is the essence of what apple calls Drag and Drop installation.
Unfortunately, installing web applications has not reached this level of ease of use refinement. An end user oriented web application might require that you:
- Download to your local machine (Using browser)
- Unpack (using 3rd party archive tool)
- Locate and edit configuration files, potentially requiring a knowledge of file system paths on the server, database names, etc.
- Upload (Using yet another tool, such as ftp)
- Change file permissions to allow files to be written to some directories on the server
- Install external components, such as pear modules
- Compile PHP to include required modules
- Edit .htaccess to setup include_path’s and mod_rewrite
Hardly “Drag and Drop.” It would be nice to have something like a drag and drop capability for end users. In this case, the applications could just be moved to the desired location in DOCUMENT_ROOT and run by pointing the browser to it.
Apple has several supporting technologies that facilitate drag and drop install:
Grouping
“Bundles provide an elegant solution to the problem of grouping related code and resources together.” PHP has the tarball or the zip file, but this requires an unpacking stage. If the user lacks shell access, then the unpacking stage must occur offline. Where is the PHP equivelent of the .JAR or the .WAR? How can the unpack stage be eliminated?
Hiding
One of the advantages of the bundle is the ability to hide internal resources from the end user. Web applications have the need to hide internal resources. Typically, this can be done with PHP by moving files outside of your DOCUMENT_ROOT (adding another installation stage), hiding resources with .htaccess, or giving them .php extensions when possible (typically for config files). Hardly end user friendly techniques.
Sharing
Frameworks are a special type of bundle designed for distributing shared code and resources.
Frameworks have a version capability that helps manage DLL Hell situations, where installing or upgrading one application breaks another via shared dependencies. A Framework bundle may contain multiple versions of the same code, and the OS will link to the correct one. Additionally, framework bundles can be embedded into Application Bundles, so that application will always have a usable version available. Embedding helps facilitate drag and drop install because an additional step is not needed to install shared resources.
I think embedding shared resources (libraries like adodb and wact) is the best way to go for application deployment.
Unfortunately, I think PEAR takes a shared commons attitude and resists embedding because of its desire to be in the include_path.
Preferences
User configuration in OS X is stored in preference files, which are independent files named by application. Well behaved OS X application operate even with their preferences files missing. deleting an applications preference file causes the application to recreate it with the default preferences. (Try deleting an application’s registry keys under windows and see how things go.)
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
A wish list, i am sure.
What are best practices for deploying PHP web applications? What applications do this well?
All Posts
November 24th, 2004 at 7:56 pm
To a certain extent there are various PHP Jar implentations, such as PHAR (http://pixelated-dreams.com/blog/archive/000058.html), though they fail in allowing easy one-click configuration.
One thing that is difficult though is data storage. You are generally going to need either a database or flat files. With a database, you need a configuration (to connect and for table names and so on), while flat files gets you back into filesystem permission problems… so there really isn’t an easy way to get things working.
November 24th, 2004 at 8:27 pm
I’d say PEAR takes a fairly good approach, because in most cases it’s installed in a global place, which isn’t the same between distros, which of course is a down side, but hey what can we do
Think include path is a good way for the users to being able to move things around between servers, but another alternative comes to mind that is doable, introduce the PEAR_PATH (or whatever) constant that has the global dir path of PEAR, but that would require all PEAR packages and end user when including PEAR stuff to use PEAR_PATH infront in all include/requires, in the same way as WACT does it with WACT_ROOT and similar, a constant that can be overwritten at run time, that way frameworks like WACT could more easily use PEAR I guess, or what ?
November 24th, 2004 at 9:31 pm
Whilst PHAR is far from finished (it was working just FINE till I tried to implement gzip’ing of data, BAH!), when I am done with the package, it will be possible to add/remove/update files in the archive - from files in the archive itself, thus allowing you to do the following:
1) Set the init script to be a web configurator
2) take the data input and write a configuration file to the archive
3) remove the original init script
4) write a new init script with the standard frontend (i.e. your forum home page)
Hope that makes sense in my sleep deprived state!
- Davey
November 25th, 2004 at 6:14 am
You can have multiple PEAR installations. Also you can dynamically set the include_path. So if you route all your requests through a common file then its fairly simple to use whatever libs that have been bundled with the app (including PEAR packages).
Automatically installing application data is kinda tricky indeed. Flatfile/SQLite makes things a bit simpler, especially on simple OS’s like windows. But upgrading is still tricky then. Unfortunately the MDB xml schema doesnt seem to have taken off in terms of use, but it can help a ton there since it can automatically alter a database (SQLite 2.x doesnt support alter table though). However I think its ok to go through a web installer in order to type in some needed conf options. Then again I dont believe that drag&drop installation is really the way to go, especially for stuff that I download off the net and that expose themselves (and what data they can access) to the net.
November 26th, 2004 at 1:28 am
Think the basic conclusion then some kind of installer program is needed. The problem there though can be installing the installer.
Think PEAR proves this. Of the top of my head, required knowhow to setup the PEAR installer;
- Understanding of operating system environment variables (possibly including .profile or registry modification)
- Understanding of the the PATH environment variable works and how an OS searches it
- Understanding how PHP’s include path works
Have a read of some of the comments here - possession of such knowledge cannot be assumed. And if you can’t install the installer, you’re shut out. The result is I think the PEAR installer will only ever be a tool for the experienced.
Given also that PHP installations vary and that differences between SAPIs can be significant (e.g CGI vs. Apache vs. CLI) for critical functions like getcwd(), in addition to any security restrictions imposed by run scripts under the web server, I don’t believe that PHP is the right tool for a generic PHP installer.
Installers designed for a single application (eZ publish is an excellent example) can work well but you still need to unpack an archive somewhere.
What’s proved successful as a model for an installer is one that doesn’t need installing itself. Windows setup.exe programs for example (of which there are a few Open Source options such as Nullsoft Installer and Windows Installer XML. There are a some problems here though
- there isn’t a generic, cross platform solution (that I’m aware of)
- on *Nix systems, things like RPMs typically require priveliged access (and assume you can access the shell in the first place, which is not the case on all shared hosts). Also “stand alone” installers (an installer that doesn’t itself need installing) are not common for *Nix applications - Firefox for Linux is a very rare exception, as far as I’m aware. The notion of “package management” is more common in *Nix operating systems.
- they are, typically, geared for local installation. Meanwhile the typical installation procedure for someone installing a PHP app, I assume, is;
1. download from website
2. modify any config files locally
3. trasfer (FTP, SCP, whatever) to shared host
More to this rant coming; posting this first
November 26th, 2004 at 2:44 am
Rant continued;
From where I stand think PHP is the wrong tool to write an installer for PHP applications - although it’s become less true with time, PHP is not a general purpose programming language and, in general, PHP is not used standalone - usually runs under a web server.
As I see it some better alternatives include;
- Python.
Is well supported on *Nix, Mac and Windows and Python comes within distribution tools built-in (see here). These can be used to install other things, apart from Python scripts (see here). That means, for someone with Python installed, they just need to type;
$ python setup.py
And it’s done.
But if they don’t have Python installed, further options exist (at least for Windows and Mac) which allow you to distribute a ready-to-execute program (see py2exe [Windows] and py2app (Mac)), bundling the Python dlls. It may be possible to use this to create a self installing PHP application.
Further ease of use could be provided with wxPython to make a GUI-based interactive installer that will run on *Nix, Mac and Windows. That’s alot more work but would be interesting to explore as an avenue for allowing installation directly to a remote web server (Python has excellent networking tools as well).
Either way there’s alot to be learned from Python methinks.
- Firefox
Would be real nice to have an extension that allows you to right click on a download from the Firefox download manager (if the download has the right file extension / mime-type say) and install it. Again lots of work but Firefox + extension are very easy for users to set up and are cross platform. Mozilla’s XPCom also makes networking a possibility, via Javascript so having a remote installer would be possible (for someone with infinite time ;))
May also be possible to employ Mozilla’s extension installer XPInstall for other uses, although I expect it will restrict you to installing into the Mozilla diretory.
A third angle, which I’m not sure could be applied but may have potential is something like they’ve done with Blogtorrent - see how it works. Seems you can “tack on” extra files on the fly, to a Nullsoft installer program. Windows only though
November 26th, 2004 at 9:07 am
Harry, your python comment presumes that the user has command line access. I think many php installation procedures assume this, and it is not necessarily true. Especially for consumer oriented web applications (say gallery or wordpress).
The point of “Drag and Drop” install is that there isn’t an installer. As you say: “What’s proved successful as a model for an installer is one that doesn’t need installing itself.” Indeed, part of what makes drag and drop work on the Mac, is that the environment is built for it. The question I ask is why can’t PHP streamlined for the task of installing web applications. It is without a doubt the most widely deployed language. It already has more end-user oriented software than anything else. Why can’t the PHP community now spend some effort on usability refinements to cement that leadership?
Also, I don’t mind that an application has a online configuration stage, hopefully as minimal as possible. As long as the application can get to the configuration stage without requiring configuration.
The goal is too minimize the number of different tools the user needs to get from step A to step B and to eliminate as many intermediate steps as possible.
December 2nd, 2004 at 2:50 pm
Here are just my 2 cents: perhaps it is - for the time being - unkown that there is a php-package-maker available, which comes AFAIK near to what Jeff is looking for. Unfortunately for some of the guys out there the information is only in German. But hey, why not dive into the code?
To make a long story short: there are two ways for installing.
The first option needs a separate
php-package-installer, which once uploaded will always install all thephinstaller-packagesit will find.The second and more interesting option is the
self-extracting-package. According to the description there are the possibilities of deleting the package after installation or the execution of asetup.php, if available.Well, it seems that this could be a good start for further development, does it not?
December 19th, 2004 at 7:04 am
I just read the post and this came to mind:
http://izforge.com/izpack/
The only limitation would be that you have to have java installed, but it does run on the main OS’s
Nick
March 8th, 2005 at 6:34 pm
I think a lot can be done and has been accomplished through various package managers and PEAR. However, I see an unfair comparison between a “Mac like” install and an install on a hosted server with limited priviledges. After all, on the Mac, you are at your computer; you have access to the console; and you have all permissions.
Aside from that:
1) dependencies (ie, MySQL) are ok as long as they can be installed just as easily.
2) mimick *nix installs, with config files in user dir (ie, /home/webapps), so upgrades don’t override user config.
3) …more
The biggest thing may be to agree upon a standard. We’ll also need a repository with packages checked for proper build by a trusted group.
September 4th, 2005 at 7:22 pm
In the windows world, drag-n-drop installs are generally known as “malware”. In the Mac world, it is the ideal. Go figure.
April 23rd, 2007 at 10:43 pm
I have a mac and I can’t find a program to set up the files I download, I have them on my computer but it seems none of the applications will run the file, is there anything you can recommend?
June 16th, 2007 at 7:46 pm
Another thought for ease of installation would be a top down 1 long PHP script distribution (the only caveat is that it would require the user PHP/apache is running as to have write access to the file system where the script is running).
Anyway, the theory is this: The automated tool parses the directory structure and makes a list of the php folders and files. It then brings all of the directory structure making code into the first part of this php file. Then, it brings in the code for each PHP file into the source as well. So, when you “drag and drop” the code into the location, and run it, it makes the distribution (and possibly can delete itself? I haven’t thought this idea out…)
Then, any data could also be imported into the end (sql insertion etc…)… but this would require configuration questions as the script runs - which are still easy to do.
Finally, any website that serves these php files would send a header of plain text for the .php files in their download section. This way, you’d get ‘aaronsAwesomeProgram.php’ with the proper extension ready to be executed (without being processed on the host machine).
I’m sure there are errors in this - because I just thought of it off the top of my head… and I apologize if any of the packages mentioned above do this - I haven’t had a chance to check them out yet.
Finally, as an afterthought - the mac installation - the windows installation, both are desktop environments primarily… When you’re installing something on a server, the security model is usually different (for example, the last time I installed something on a windows 2003 server, I had to run-as and authenticate as an administrator)… so, where most PHP scripts are running, they are under more strict security models as well - kind of getting rid of this whole drag and drop installation paradigm.