On Jun 26, 2008, at 11:38 AM, Kevin Brown wrote:
Hmm -- ultimately though, won't this just wind up bundled in a tar
ball or
something? Perhaps we could have a simple "build" script for the PHP
code
that takes care of copying things to the right places. We could drop
in a
minification pass for the javascript while we're at it.
That is something i have considered before, especially when we were
talking about the javascript mimification (remember those threads,
month or 2 back).
However my big fear was, and still is really, that there will be a lot
of people who just want to 'ftp their files to their shared web
host'.. that audience probably has no idea about how bash works, let
alone more advanced stuff like build scripts and dependencies. I don't
even know if i can count on a command line/cli version of PHP being
available in general ... and if it is, if it's the same version as the
website (lots of bit messier web hosting companies have an upt-to-date
php & apache self-compiled, but standard distro php (v4.x).. *shudder*).
Really the amount of assumptions i can make about the platform is
incredibly limited, unless of course i make the choice to exclude all
but the more professional who have some basic system administration
background, my experience is though that that would exclude about 50%
of our potential audience on the php side (to give you an example:
setting up a basic shindig config is marked down as 'hard' already at
the code labs, because it involves making a vhost config in apache..)
So i'm extremely weary off and careful with adding any extra
'assumptions' to the requirements, and running a 'script' of any
kind ... well that adds a lot of assumptions already (tcsh? bash? sh?
which cli php version if any? windows, solaris, linux, bsd or? do they
even have shell access? many shared hosts do not). Scary territory to
thread into.
Thats the reason i went for on-the-fly compression of the javascript
files (though the results are cached, per feature so the performance
his is limited even on the first hit), it just by-passes a lot of
potential problems.
and on making a release tar ball, we simply change the default config
from <web root>/../javascript to <web root>/javascript .. or maybe
even leaving things as is since it's not so horrible not to have files
that shouldn't be served from apache outside of the web root anyhow.
-- Chris
