Hello Alex!
I have read in another thread that you are engaged in the further development of the Build area routines. I just thought of throwing some of my ideas. Based on the thread Links SQL v2.0 beta in the Question forum or where ever it was I would like to continue the following:
I was facing a situation a year ago after the number of links increased to 2500 and categories to 1000!!! The processor power available was not enough for the hungry Links SQL nph-build.cgi script. It produced about 500 pages and then got killed. Telnet DOES not help as this was due to the root killing the process. What I suggest is as follows:
-----------------------------------------------------
1. MODULE LISTINGS AND NAMING
Include in every script or a module as follows before you distribute a stable or a beta.
Use Custom.pm;
Use Category.pm;
Use Build.pm;
Use Banner.pm;
Please make an identification of basic functions and make separate modules. Later on only those modules needs to be updated. If everyone has Custom.pm written in his or her script then all the subroutines could be written there with another or the same name. All those subroutines will be instantly available to all the scripts. Advantage is that customized subroutines could remain in there and later on updates could be done of remaining standard modules. So then I will also have a list of specific custom routines that will not be disturbed.
Now if I have to go through all the scripts again and see where I have done some tweaking that's a disaster. Last time I made a remark and you and Brian gave me lots of nice suggestions as to Ultra-Edit etc. However I still maintain that this would be an excellent approach and is not harmful at all. By doing so, you could also provide an update script that would seamlessly update the standard modules in their respective directories without disturbing or deleting the Custom.pm
-----------------------------------------------------
2. BUILD ROUTINES LOGIC
Editor can run nph-build.cgi and queries could be made before hand. What I propose is that nph-build.cgi process could be invoked only after the Admin decides what needs to be done. It will then use
Editor.cgi >>> SQL Queries and presentation to admin.
>>> Build.pm >>> Choice
>>> nph-build.cgi >>>> finally builds.
-----------------------------------------------------
3. REMOVE VALIDATE TABLE.
Validity of the Validate table is invalid!!!
Till today I have not understood the REAL necessacity of Validate table. Everything could be handled from Links table with the help of Status of a link or a user. It is just creating complications.
-----------------------------------------------------
4. STATUS DEFINITION OF EACH LINK
Use only links table with codes
N = New
M = Modify
D = Dead or to Delete
P = Popular
C = Cool
S = Special
Etc
This also helps that before build, one can run nph-verify right away. If the server does not answer it gets a status D. "No unnecessary build of unnecessary links".
-----------------------------------------------------
5. REMOVE STATS RELATED TO EVERY CATEGORY in the early build process
Simply because every Category needs to be together with stats Category (e.g. 132) in the beginning build area, it becomes difficult to build by parts. Therefore, if this is done at the end while building the main important pages of the categories and homepage, then one can build
FROM THE BRANCH TO THE ROOT CONCEPT!
-----------------------------------------------------
6. DELETE SUBROUTINE FROM LINKS TABLE
With one click it would
- Delete all the links that are dead or to be deleted,
- Reshuffle the Links towards the top in the Links Table
- Re-index at the end.
-----------------------------------------------------
7. EDITOR.CGI >>> VIEW CASES FOR LINKS TABLE
Many of the users have forty to seventy Columns. Therefore, if the editor.cgi enters into the view-mod with a similar programming of now
CASE: {
$in->param('view-columns') && do { $msg = &get_columninfo ($in, $db); last CASE; };
};
Editor.cgi will then generate an admin page, which offers further options listing all the columns available to choose, one could click and will present only those columns to view for the purpose of Validation FROM THE LINKS TABLE!
Therefore one may choose only three columns to view for the Validation. This will not generate a GIANT WebPages of seventy-column information X 10 Links. People having sixty seventy columns will have about 100 - 150 KB of a web page to download that has link information for 10 Links. This is less efficient and uses unnecessary resources. For e.g. while validating a link I only need to see the description of the link and check if there is something abusive and that's all.
-----------------------------------------------------
8. EDITOR.CGI >>> FUNCTION CHOICE >>> QUERIES RELATED TO BUILD PROCESS
One can chose as follows:
Full Links table build
Category builds ONLY
Sub-category builds ONLY
-----------------------------------------------------
9. ACTUAL BUILD SEQUENCE OF NPH-BUILD.CGI
FROM THE BRANCH TO THE ROOT CONCEPT!
By doing this way, one secures that there will be no confusion and wrong diversions of the links with respective to their Links LDs.
-----------------------------------------------------
10. Please keep on listing somewhere things that are under development including functions and subroutines or something like that.
I have read in another thread that you are engaged in the further development of the Build area routines. I just thought of throwing some of my ideas. Based on the thread Links SQL v2.0 beta in the Question forum or where ever it was I would like to continue the following:
I was facing a situation a year ago after the number of links increased to 2500 and categories to 1000!!! The processor power available was not enough for the hungry Links SQL nph-build.cgi script. It produced about 500 pages and then got killed. Telnet DOES not help as this was due to the root killing the process. What I suggest is as follows:
-----------------------------------------------------
1. MODULE LISTINGS AND NAMING
Include in every script or a module as follows before you distribute a stable or a beta.
Use Custom.pm;
Use Category.pm;
Use Build.pm;
Use Banner.pm;
Please make an identification of basic functions and make separate modules. Later on only those modules needs to be updated. If everyone has Custom.pm written in his or her script then all the subroutines could be written there with another or the same name. All those subroutines will be instantly available to all the scripts. Advantage is that customized subroutines could remain in there and later on updates could be done of remaining standard modules. So then I will also have a list of specific custom routines that will not be disturbed.
Now if I have to go through all the scripts again and see where I have done some tweaking that's a disaster. Last time I made a remark and you and Brian gave me lots of nice suggestions as to Ultra-Edit etc. However I still maintain that this would be an excellent approach and is not harmful at all. By doing so, you could also provide an update script that would seamlessly update the standard modules in their respective directories without disturbing or deleting the Custom.pm
-----------------------------------------------------
2. BUILD ROUTINES LOGIC
Editor can run nph-build.cgi and queries could be made before hand. What I propose is that nph-build.cgi process could be invoked only after the Admin decides what needs to be done. It will then use
Editor.cgi >>> SQL Queries and presentation to admin.
>>> Build.pm >>> Choice
>>> nph-build.cgi >>>> finally builds.
-----------------------------------------------------
3. REMOVE VALIDATE TABLE.
Validity of the Validate table is invalid!!!
Till today I have not understood the REAL necessacity of Validate table. Everything could be handled from Links table with the help of Status of a link or a user. It is just creating complications.
-----------------------------------------------------
4. STATUS DEFINITION OF EACH LINK
Use only links table with codes
N = New
M = Modify
D = Dead or to Delete
P = Popular
C = Cool
S = Special
Etc
This also helps that before build, one can run nph-verify right away. If the server does not answer it gets a status D. "No unnecessary build of unnecessary links".
-----------------------------------------------------
5. REMOVE STATS RELATED TO EVERY CATEGORY in the early build process
Simply because every Category needs to be together with stats Category (e.g. 132) in the beginning build area, it becomes difficult to build by parts. Therefore, if this is done at the end while building the main important pages of the categories and homepage, then one can build
FROM THE BRANCH TO THE ROOT CONCEPT!
-----------------------------------------------------
6. DELETE SUBROUTINE FROM LINKS TABLE
With one click it would
- Delete all the links that are dead or to be deleted,
- Reshuffle the Links towards the top in the Links Table
- Re-index at the end.
-----------------------------------------------------
7. EDITOR.CGI >>> VIEW CASES FOR LINKS TABLE
Many of the users have forty to seventy Columns. Therefore, if the editor.cgi enters into the view-mod with a similar programming of now
CASE: {
$in->param('view-columns') && do { $msg = &get_columninfo ($in, $db); last CASE; };
};
Editor.cgi will then generate an admin page, which offers further options listing all the columns available to choose, one could click and will present only those columns to view for the purpose of Validation FROM THE LINKS TABLE!
Therefore one may choose only three columns to view for the Validation. This will not generate a GIANT WebPages of seventy-column information X 10 Links. People having sixty seventy columns will have about 100 - 150 KB of a web page to download that has link information for 10 Links. This is less efficient and uses unnecessary resources. For e.g. while validating a link I only need to see the description of the link and check if there is something abusive and that's all.
-----------------------------------------------------
8. EDITOR.CGI >>> FUNCTION CHOICE >>> QUERIES RELATED TO BUILD PROCESS
One can chose as follows:
Full Links table build
Category builds ONLY
Sub-category builds ONLY
-----------------------------------------------------
9. ACTUAL BUILD SEQUENCE OF NPH-BUILD.CGI
FROM THE BRANCH TO THE ROOT CONCEPT!
By doing this way, one secures that there will be no confusion and wrong diversions of the links with respective to their Links LDs.
-----------------------------------------------------
10. Please keep on listing somewhere things that are under development including functions and subroutines or something like that.