The code in the git repository has a bash script called quickstart that installs an apache web server with PHP, both from source using wget. It reminds me of Gentoo portage, but not so robust. The script requires no configuration at all, because it installs and runs the server as, and for, a regular user in a 'non system' directory in sub directory of the untared source tree. The project is currently in a pre-pre-alpha state, so it is only useful for developers. This is the coolest developer script ever written. The idea is that you checkout the source and run one script in the source and "bang!' a browser opens to the projects top server directory index. It currently works on a fairly standard Ubuntu system. If anyone ever runs this script, please let me know if it worked, or not.
Last edit: Lance Arsenault 2013-01-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(not the facebook PHP compiler) tableforms keeps installed files separate from source code files. This idea seems foreign to most PHP web service projects. Most packages just dump the source files into a web server directory and than some edits are made to the files in an automated and/or non-automated way, and that is called 'installed'. That's not a problem so long as you're just a user and not a developer. For a developer you must distinguish between source files, and installed and/or generated files. tableforms builds and installs the same way a GNU autotools, or CMake C/C++ source project builds and installs. The build step does a lot of pre-computing (pre-processing) making the installed PHP run much faster. The cost in doing this is the introduction of new concepts into PHP coding. The performance gains come from having fewer system calls at serve time. I expect that it's about 2 or 3 times faster. That's just a wild guess. Running a comparison with a non-pre-processed and the current pre-processed tableforms would double the work in the project, so that's not likely to happen. The reasoning for the behind this performance increase is because we know that doing some tasks once before running a script is faster than having to do the task each time the script runs; or put another way doing nothing is always faster than not doing something (at least at serve time). It's quite obvious. The build/install concept adds speed to the service. It also helps developers have a clear division between source files and installed instances. From a single tableforms source directory tree you can make any number of installed independent instances. Fun stuff...
This idea of compiling PHP and then installing the "compiled" PHP on the server introduces the idea of "compile-time PHP code" and "serve-time PHP code". It's similar to idea of C-pre-process (CPP) code and C code, but there can be more pre-process (compile-time) PHP code than serve-time PHP code, where in most cases there's more C code than CPP code in a C source code project.
We define <@php@ and ?> as the opener and closer for the serve-time PHP code. We run the script once at compile time, replace <@php@ with <?php, and then run resulting script N times at serve time. I was very surprised when it worked. The <@php@ and extra ?> were just ignored by PHP on the compile run. I need to get vim to do the right syntax highlighting for <@php@, so the all the PHP code in the <@php@ ?> looks better. The quick fix is to replace <@php@ with <?@php@ while editing a section and than change it to <@php@ before compiling. If I forgot to change the <?@php@ back before compiling it would sometimes still compile and than running it (requesting the page) would usually point out my error very quickly.
Last edit: Lance Arsenault 2013-01-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In tableforms we minimize duplication in the source files, so that changes and additions do not hamper our evolution. We also minimize duplication in the intermediate serve-time meta data files. The idea is that we want to enable changes in the basic source files to be able to be pushed up to the end user in an automated fashion, i.e. you shutdown the service, run a reinstall script, and then restart the service to get changes in source pushed to your customers. (You would not trust such a reinstall procedure, but throwing in some file copying and some testing here and there, some variant of this "server engine rebuild" could be done while preserving most of the perceived customer data.)
Clearly, using a data base server for all the customer data makes a server engine rebuild trivial by comparison. But wait, using a data base server just displaces this version update problem. You'll have to reformat/restructure the data in the data base in place of what we call recompiling the generated files.
Data bases cost in serve-time performance and complexity, but give back in the ability to find relations, search and more like things. A couple of HTML forms on a web site don't need that. tableforms is simple and does not use a data base to store what are "fast assess" static files.
Just because WordPress uses a data base and most of the rest of the world uses a data base, that does not mean that we should. Popularity is a good argument. But we opted for performance over popularity. We don't envision that standard file systems will be completely replaced by relational data base servers, seeing as current relational data base servers are built on standard file systems, or at least the ones I have access to. So, in conclusion, get off my f---ing case about using relational data base servers.
Because tableforms does not use a data base server does not mean it can't be used as a plugin into WordPress. tableforms is CMS-agnostic, with just a little plugin code added for each CMS.
Last edit: Lance Arsenault 2013-01-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since GNU autotools, and CMake do not work well with PHP/javaScript/HTML/CSS files projects, we made our own package build system with Bash and GNU make. The top level installer interface to it is like GNU autotools, where in you run './configure', 'make', and 'make install' to install an instance of tableforms. We strive to keep a well defined interface for this "new" build system, so that we may spin it off as another project.
We looked for an existing build system for this PHP/javaScript/HTML/CSS project but we did not find one. We think the idea of building and install a PHP/javaScript/HTML/CSS based project is somewhat novel.
Authentication System
We looked for an existing authentication system to use too. We failed to find one of those we liked too. Most freely available web authentication systems only do a small subset of what is needed, it's either that of they do way too much. Using a full blown CMS just to do authentication would impose to much on the package, so we didn't do that; well there's that and most CMSs have a very slow authentication system, compared to what we made.
So we made a web authentication system too. We have found it difficult to keep the interfaces to the authentication cleanly defined, but if, and when, we clearly define these authentication interfaces an authentication package/project can be spun-off.
So far the authentication has a very simple design, which looks to be very robust at the same time. It does not use a relational data base server. Using a relational data base server just to store passwords and a couple account parameters seem pointless. Your using a powerful "relational" engine to store "non-relational" data. WTF. It's a big waste of resources. Why the F--- would you want to find relationships in usernames and passwords. The only relation needed is username to password look up. A file can do that, thank you, and at least 2 times faster then by using a relational data base server. And believe it or not you can read and write to files atomically.
It also looks like the authentication system should scale well too. We should
be able to make an account for every person on the planet on my netbook with plenty of room to spare.
Last edit: Lance Arsenault 2013-01-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quickstart for developers
The code in the git repository has a bash script called quickstart that installs an apache web server with PHP, both from source using wget. It reminds me of Gentoo portage, but not so robust. The script requires no configuration at all, because it installs and runs the server as, and for, a regular user in a 'non system' directory in sub directory of the untared source tree. The project is currently in a pre-pre-alpha state, so it is only useful for developers. This is the coolest developer script ever written. The idea is that you checkout the source and run one script in the source and "bang!' a browser opens to the projects top server directory index. It currently works on a fairly standard Ubuntu system. If anyone ever runs this script, please let me know if it worked, or not.
Last edit: Lance Arsenault 2013-01-17
Compiling PHP with PHP
(not the facebook PHP compiler) tableforms keeps installed files separate from source code files. This idea seems foreign to most PHP web service projects. Most packages just dump the source files into a web server directory and than some edits are made to the files in an automated and/or non-automated way, and that is called 'installed'. That's not a problem so long as you're just a user and not a developer. For a developer you must distinguish between source files, and installed and/or generated files. tableforms builds and installs the same way a GNU autotools, or CMake C/C++ source project builds and installs. The build step does a lot of pre-computing (pre-processing) making the installed PHP run much faster. The cost in doing this is the introduction of new concepts into PHP coding. The performance gains come from having fewer system calls at serve time. I expect that it's about 2 or 3 times faster. That's just a wild guess. Running a comparison with a non-pre-processed and the current pre-processed tableforms would double the work in the project, so that's not likely to happen. The reasoning for the behind this performance increase is because we know that doing some tasks once before running a script is faster than having to do the task each time the script runs; or put another way doing nothing is always faster than not doing something (at least at serve time). It's quite obvious. The build/install concept adds speed to the service. It also helps developers have a clear division between source files and installed instances. From a single tableforms source directory tree you can make any number of installed independent instances. Fun stuff...
This idea of compiling PHP and then installing the "compiled" PHP on the server introduces the idea of "compile-time PHP code" and "serve-time PHP code". It's similar to idea of C-pre-process (CPP) code and C code, but there can be more pre-process (compile-time) PHP code than serve-time PHP code, where in most cases there's more C code than CPP code in a C source code project.
We define <@php@ and ?> as the opener and closer for the serve-time PHP code. We run the script once at compile time, replace <@php@ with <?php, and then run resulting script N times at serve time. I was very surprised when it worked. The <@php@ and extra ?> were just ignored by PHP on the compile run. I need to get vim to do the right syntax highlighting for <@php@, so the all the PHP code in the <@php@ ?> looks better. The quick fix is to replace <@php@ with <?@php@ while editing a section and than change it to <@php@ before compiling. If I forgot to change the <?@php@ back before compiling it would sometimes still compile and than running it (requesting the page) would usually point out my error very quickly.
Last edit: Lance Arsenault 2013-01-17
Home Page
We'll make a tableforms home page when we make the first tarball release. For now the project may as well be a secret.
Last edit: Lance Arsenault 2013-01-17
Relational data base servers and tableforms
In tableforms we minimize duplication in the source files, so that changes and additions do not hamper our evolution. We also minimize duplication in the intermediate serve-time meta data files. The idea is that we want to enable changes in the basic source files to be able to be pushed up to the end user in an automated fashion, i.e. you shutdown the service, run a reinstall script, and then restart the service to get changes in source pushed to your customers. (You would not trust such a reinstall procedure, but throwing in some file copying and some testing here and there, some variant of this "server engine rebuild" could be done while preserving most of the perceived customer data.)
Clearly, using a data base server for all the customer data makes a server engine rebuild trivial by comparison. But wait, using a data base server just displaces this version update problem. You'll have to reformat/restructure the data in the data base in place of what we call recompiling the generated files.
Data bases cost in serve-time performance and complexity, but give back in the ability to find relations, search and more like things. A couple of HTML forms on a web site don't need that. tableforms is simple and does not use a data base to store what are "fast assess" static files.
Just because WordPress uses a data base and most of the rest of the world uses a data base, that does not mean that we should. Popularity is a good argument. But we opted for performance over popularity. We don't envision that standard file systems will be completely replaced by relational data base servers, seeing as current relational data base servers are built on standard file systems, or at least the ones I have access to. So, in conclusion, get off my f---ing case about using relational data base servers.
Because tableforms does not use a data base server does not mean it can't be used as a plugin into WordPress. tableforms is CMS-agnostic, with just a little plugin code added for each CMS.
Last edit: Lance Arsenault 2013-01-17
Spin off projects?
Build System
Since GNU autotools, and CMake do not work well with PHP/javaScript/HTML/CSS files projects, we made our own package build system with Bash and GNU make. The top level installer interface to it is like GNU autotools, where in you run './configure', 'make', and 'make install' to install an instance of tableforms. We strive to keep a well defined interface for this "new" build system, so that we may spin it off as another project.
We looked for an existing build system for this PHP/javaScript/HTML/CSS project but we did not find one. We think the idea of building and install a PHP/javaScript/HTML/CSS based project is somewhat novel.
Authentication System
We looked for an existing authentication system to use too. We failed to find one of those we liked too. Most freely available web authentication systems only do a small subset of what is needed, it's either that of they do way too much. Using a full blown CMS just to do authentication would impose to much on the package, so we didn't do that; well there's that and most CMSs have a very slow authentication system, compared to what we made.
So we made a web authentication system too. We have found it difficult to keep the interfaces to the authentication cleanly defined, but if, and when, we clearly define these authentication interfaces an authentication package/project can be spun-off.
So far the authentication has a very simple design, which looks to be very robust at the same time. It does not use a relational data base server. Using a relational data base server just to store passwords and a couple account parameters seem pointless. Your using a powerful "relational" engine to store "non-relational" data. WTF. It's a big waste of resources. Why the F--- would you want to find relationships in usernames and passwords. The only relation needed is username to password look up. A file can do that, thank you, and at least 2 times faster then by using a relational data base server. And believe it or not you can read and write to files atomically.
It also looks like the authentication system should scale well too. We should
be able to make an account for every person on the planet on my netbook with plenty of room to spare.
Last edit: Lance Arsenault 2013-01-17