Subject | Re: Name for the Phoenix PHPServer Stack |
---|---|
Author | paulruizendaal |
Post date | 2005-09-16T13:49:04Z |
Hi all,
I thought it already had a name: "Phoenix PHPServer"
Actually, I think we should not go down the route of bastardized LAMP
acronyms. It hasn't worked for anybody else, why should it work for
us?
In my opinion we should just call it "LAMP" and hammer down the
message that LAMP these days is a development paradigm, not a
specific set of components:
- The components in LAMP have shifted over time anyway
- Developers already use "LAMP" to say "web app with server side
scripting"
- Many industry participants have a vested interest in shifting the
meaning of LAMP in this way; let's not be lonely ponies.
Coining new acronyms for LAMP has been tried from several sides and I
don't think it has worked in any case. Bending the meaning of a
phrase is a tried and tested method of politicians and MS ("embrace
and extend"). Not inspiring examples, but it works.
Paul
PS:
For those historically interested, a few factoids:
- the basic elements of interactive web pages (html <FORM> tag, http
POST method, cgi server API) appeared around 1993, but were not
commonly available until 1995. The server side language were unix
shell scripts, no database in sight.
http://www.anu.edu.au/people/Roger.Clarke/II/WCBirth.html
- David Hughes is the inventor of the LAMP stack, presenting all
concepts to a March 1996 conference. His solution includes a
lightweight SQL engine ("mSQL") and a server side embedded scripting
language ("W3-mSQL/Lite") running as cgi module. The stuff is open
source, but the license is restrictive.
http://web.archive.org/web/19990219215138/www.hughes.com.au/library/li
te/qauug96/
- PHP gets started as a set of perl scripts in 1995. It remained, by
and large, a one-man project as late as 1997.
http://nl2.php.net/history
- Monty Widenius is a mSQL user, but finds preformance lacking. He
releases an API-compatible mSQL clone under the GPL, called MySQL, in
1997
- Michael Kunze coined the acronym LAMP in an article for the German
computing magazine c't in the summer of 1998 (12/98, page 230). He
uses it for Linux-Apache-mSQL/MySQL-Perl/PHP software stack.
http://en.wikipedia.org/wiki/LAMP_(software_bundle)
- The 1999 O'Reilly book "mSQL and MySQL" still talks about David
Hughes' stack, mSQL and MySQL, and Perl and PHP as equivalent
components in a LAMP stack. The book does not use the phrase LAMP,
though.
http://www.amazon.com/exec/obidos/tg/detail/-/1565924347/002-7811298-
5052863?v=glance
- Early in 2000, Larry Wall joins O'Reilly and Tim -- who saw the
potential of the web as an app delivery platform early on -- starts
to push the LAMP concept in the sense of Linux-Apache-MySQL-Perl. The
acronym starts to catch on.
- From 1998 to 2004, the LAMP concept rises to prominence. The
components that benefit most are Linux, Apache, MySQL and PHP. Each
component goes through several revisions and the implementation of
David's original idea becomes stronger and stronger.
- From 2004 onwards the LAMP paradigm is implemented in numerous
ways, using a variety of software stacks. Windows-IIS-SQLServer-
VB.Net is as viable as Linux-Apache-Oracle-PHP, is as viable as OSX-
Boa-SQLite-PHP.
- By 2004 browsers had evolved and standardised enough that cross-
platform client side scripting became a practical option. The
relevant technologies are DHTML/Javascript and in particular
javascripts newfound ability to do http requests outside of the main
page refresh. The catch phrase is AJAX, although I think this phrase
will fade.
In essence, the LAMP paradigm is "db driven web app with server side
(and client side) scripting". That is how it started in 1996 and that
is how it has come full circle a decade later.
The user view of this is that it is now possible to centrally host an
application that can be accessed everywhere through a browser with an
end-user experience that is similar to classic VB/Delphi apps. It may
not be quite as rich, but it is good enough.
Its greatest stengths (the unix philosophy: simple, modular approach;
everything is text) is also its greatest weakness (bits of arcane
code all over the place).
I thought it already had a name: "Phoenix PHPServer"
Actually, I think we should not go down the route of bastardized LAMP
acronyms. It hasn't worked for anybody else, why should it work for
us?
In my opinion we should just call it "LAMP" and hammer down the
message that LAMP these days is a development paradigm, not a
specific set of components:
- The components in LAMP have shifted over time anyway
- Developers already use "LAMP" to say "web app with server side
scripting"
- Many industry participants have a vested interest in shifting the
meaning of LAMP in this way; let's not be lonely ponies.
Coining new acronyms for LAMP has been tried from several sides and I
don't think it has worked in any case. Bending the meaning of a
phrase is a tried and tested method of politicians and MS ("embrace
and extend"). Not inspiring examples, but it works.
Paul
PS:
For those historically interested, a few factoids:
- the basic elements of interactive web pages (html <FORM> tag, http
POST method, cgi server API) appeared around 1993, but were not
commonly available until 1995. The server side language were unix
shell scripts, no database in sight.
http://www.anu.edu.au/people/Roger.Clarke/II/WCBirth.html
- David Hughes is the inventor of the LAMP stack, presenting all
concepts to a March 1996 conference. His solution includes a
lightweight SQL engine ("mSQL") and a server side embedded scripting
language ("W3-mSQL/Lite") running as cgi module. The stuff is open
source, but the license is restrictive.
http://web.archive.org/web/19990219215138/www.hughes.com.au/library/li
te/qauug96/
- PHP gets started as a set of perl scripts in 1995. It remained, by
and large, a one-man project as late as 1997.
http://nl2.php.net/history
- Monty Widenius is a mSQL user, but finds preformance lacking. He
releases an API-compatible mSQL clone under the GPL, called MySQL, in
1997
- Michael Kunze coined the acronym LAMP in an article for the German
computing magazine c't in the summer of 1998 (12/98, page 230). He
uses it for Linux-Apache-mSQL/MySQL-Perl/PHP software stack.
http://en.wikipedia.org/wiki/LAMP_(software_bundle)
- The 1999 O'Reilly book "mSQL and MySQL" still talks about David
Hughes' stack, mSQL and MySQL, and Perl and PHP as equivalent
components in a LAMP stack. The book does not use the phrase LAMP,
though.
http://www.amazon.com/exec/obidos/tg/detail/-/1565924347/002-7811298-
5052863?v=glance
- Early in 2000, Larry Wall joins O'Reilly and Tim -- who saw the
potential of the web as an app delivery platform early on -- starts
to push the LAMP concept in the sense of Linux-Apache-MySQL-Perl. The
acronym starts to catch on.
- From 1998 to 2004, the LAMP concept rises to prominence. The
components that benefit most are Linux, Apache, MySQL and PHP. Each
component goes through several revisions and the implementation of
David's original idea becomes stronger and stronger.
- From 2004 onwards the LAMP paradigm is implemented in numerous
ways, using a variety of software stacks. Windows-IIS-SQLServer-
VB.Net is as viable as Linux-Apache-Oracle-PHP, is as viable as OSX-
Boa-SQLite-PHP.
- By 2004 browsers had evolved and standardised enough that cross-
platform client side scripting became a practical option. The
relevant technologies are DHTML/Javascript and in particular
javascripts newfound ability to do http requests outside of the main
page refresh. The catch phrase is AJAX, although I think this phrase
will fade.
In essence, the LAMP paradigm is "db driven web app with server side
(and client side) scripting". That is how it started in 1996 and that
is how it has come full circle a decade later.
The user view of this is that it is now possible to centrally host an
application that can be accessed everywhere through a browser with an
end-user experience that is similar to classic VB/Delphi apps. It may
not be quite as rich, but it is good enough.
Its greatest stengths (the unix philosophy: simple, modular approach;
everything is text) is also its greatest weakness (bits of arcane
code all over the place).