Hello Alex and Staff of GT!

After analysing a lot I came to the following conclusion (as discussed with Alex earlier):

There are many different approaches that have been undertaken fundamentally in various products that results in to diversity of functions added by differential development environments resulting into a substantial distance from a modular approach of functions. They differ in many thematic differences like functions, programming differences, etc. Instead of making a categorised discussion of each, I simply list following.

The listing below is not to be seen as a criticism in a negative manner but - my view point of what it could be - constructive discussion of each and should under no circumstances be critised by anyone or even should be seen as an attack or counter attack or even to continue a discussion in this direction thereof.

1. Different methods of password storage / encryption: Only Forum offers encryption but Gmail and Links SQL not.
2. Lost password option:This is not uniform in all products. So integration of products results into a chaos. Like Question and answer for e.g.
3. Location of FileMan and MysqlMan in Menu: In Links SQL it is linked under Menu Build and Gmail under Templates with title Templates where as in Forum under the menu Tools with title Management. For me it is very difficult to everytime "HUNT" for the function and trying to remember the product.
4. Inconsistent Menu structure: In each Product, the main menu has different structure. This is ofcourse necessary to have some differences as the product functions differs. But it is important to have some common menus under which certain functions are assigned. They actually are, upto a certain degree, but not in all cases. Best would be to have a system of structure like following: Menu 1:- Home, Menu 2 :- Product specific, Menu 3:- Product specific (Database), Menu 4 :- Email, Menu 5 :- Templates, Menu 6:- Plugins, Menu 7 :- Setup, Menu 8 :- Tools (PhpMyadmin, FileMan, MySQLMan, customisable) Menu 9 :- Userside links. Under each submenu, one needs to have similar titles.
5. Central admin for different products: This would be very easy to integrate (I have done it by inserting links in the home_nav.html as mentioned below). If quick links are given here as well, that would be excellent. If there is a central directory for the admin which has sub_directories necessary for specific products that would be excellent. Here the advantage would be that all the templates of the admin may not be necessary to update while doing an upgrade.
6. Common system of directories: For e.g. each and every product has a possibility to install directory structure like : admin, common, gmail, links, forum, tools that would be excellent. The admin directory could have all templates seperate + modules and scripts like gadmin.cgi, ladmin.cgi and fadmin.cgi etc. The tools directory would have all tools that needs to be used and is installed once and not each time seperately. Further shortcuts like quicklinks in fileman would also help in jumping from one point to anathor. Further, each product needs to have product specific scripts. In the common directory, all the library needs to go. If there is a library update, it needs to work somehow with versions mapings.
7. Naming of modules: In the same product there cannot be a module that has the same name. This needs to be a principle. Currently this is not the case.
8. Central template system: It has been a nightmare to always hunt different template location each time.Links SQL and Forum admin templates follow a consistant path /admin/templates but not Gmail. The admin templates lies somewhere under /data/admin/templates I beleive. What would help is to mention path during the installation for the templates, userside seperate, admin seperate and remaining templates seperate. By default it could offer all the path predetermined but gives the admin an extra possibilitiy to have a centralised system.
9. User templates differs: User template also are saved under data (or is it only with my installation?) in Gmail.
10. Default + Common templates naming: In Gmail and Forum they do have "common" templates but not in Links SQL, which has "default". But "default" templates are in Forum and Links SQL only. I am aware that it is possible to change the name and it would reflect immediately. But there are certainly some areas of the program in some products that remembers what the earlier configuration was. In Forum the name of the template is inserted in the database as a preference, for e.g. It is better to have one naming style. Every product has a default and or common.
11. Central (network) Globals text file: This concept did not work. What could help is one default globals.txt file and one gmail_globals.txt, gforum_globals.txt, and linkssql_globals.txt file in each could help very much. For e.g. there may be a possibility to use globals as ramdom passwords of 8 characters and numbers. This could be standard for all products. Currently one has to manually insert in each file.
12. Central Headers and Footers: If there is a possibility to specify somewhere a central path for headers and footers that could offer a centralised system for all the products for the insertion that could help. This may sound as "not possible", but I have seen its advantages.
13. Auto insert module names and Javascripts in templates: There could be a possibility to do a mapping of auto insertion of module names like <Gmail::Auth::Login> etc directly from a file since they are required by the system. A file similar to ConfigData.pm with a name ConfigModules.pm would serve the purpose. Thereafter one does not need to worry about such modules in the templates. The AutoParser.pm would automatically recognise them. Templates would be free from a lot of such programming.
14. Fileman and MysqlMan Path: In Gmail it is possible to specify Fileman path but does not work outside the root. I did not understand the reason of this possibility to specify. I wanted to have a central fileman path for all three products but did not work.
15. New Installation routines of all three products: They all differs in possibilities. Installing different path for admin and userside in Gforum does not work. I did it manually and thereafter upgrade changes the track (path) of installation! Images path is also not offered consistently in all installation routines, which are important to have them. Currently, one has to accept the behaviour of the product and then later change manually. Hence better configuration possibilities in each and every products and that to a similar approach is desired.
16. MysqlMan logins: Currently it is not possible to use Mysqlman under special circumstances where the database server is an external one and the scripts have to login eachtime for a function. For e.g. Exports - Imports. I have had problems without exceptions and messages in this regards have had no results. (Did not bother me actually!).
17. Flexible Add.cgi / Modify.cgi: This area is also one of the most important and needs a bit more developent and flexibility (to my viewpoint). For e.g. it was truely difficult to specify which file of the template it has to go in the steps of add.cgi one after the other. Here one has to use the defaults. To do something else would require a bit of attention of the admin.
18. Path to perl: This is possible only in Links SQL and not in other products.
19. Custom / Central Homepage for Admin: I have done this by myself. However, this would help all others who has more than one products. Quick links does offer this possibility however I have done it different and used home_nav.html also.
20. Use of Tables and field names: I do have problems with the choice of names. The tables contains fields that ofcourse serves the purpose but and restrictive or could have fields that could belong in a different tables. If the field list in a table would have been designed in such a manner that one could use them for different modules of external programs that would be helpful. For e.g. in the Forum_user table there are certain fields that I would have prefered in a different table. Here, there is a mix of fields that are related to universal user properties and specific of forum related fields. This table would be not useable for a modular design with other external programs. I would have prefered one user table with some universal information and other like user_forum_pref or user_gmail_pref or even user_links_pref for that function leaving the universal USER table free from the product specific function.
21. Tables available to modules of other programs: Currently, for e.g. the information collected in the users tables could be used ofcourse by different external programs but with difficulties. Since they contain information of the specific product like in forum_users_table it is NOT possible to use it.
22. Installation routines: Needs to be a bit more developed in terms of locations of paths and configurations. Most importantly they need to be atleast similar to offer a centralised system in terms of upgrade possibilities of templates + cgis, global centralised templates, etc. Also different steps of installation routines would also help, for e.g. docs opened seperately.
23. Common Stylesheets and Gestaltung Tags: It is truely difficult to remember different tags in different products. They differ in each tremendously. Up to a certain extent _They_Have_To_ but if there is some consistency that would help a lot. Like for e.g. if there is a Body tag or table tag that could be used globally that would help by using the same file. So there is no difficulty to bring every parameter in different product. I know this is possible but during the work with different products it seemed difficult and a possibility out there would help.
24. Common language files: There are many functions that require the same or common display of language files or tags. For e.g. login errors are the same. I have known how to use them but a possibility would be great.
25. Mailing system: Mass Mail, Newsletter, Mailing list, subscribtions system in all three products works and functions differently or is eventually missing.
26. Better Search and Statistics: In all the products is a wish.

To compare all the functions as discussed above do the following:

Add in the home_nav.html of admin in each products somewhere BEFORE the table <TD> tag

<td><font face="Tahoma,Arial,Helvetica" size="4">
&nbsp;<a href="admin.cgi?do=page;page=home_body.html">Home</a> |

ADD THE FOLLOWING:
<td><font face="Verdana,Arial,Helvetica" size="2">
Links (related product) Admin</font>
<font face="Verdana,Arial,Helvetica" size="0">|
<a href="(correct path)admin.cgi?" target="_parent">Links</a> |
<a href="(correct path)admin.cgi?" target="_parent">EMail</a> |
<a href="(correct path)admin.cgi" target="_parent">Forum</a> |

All above leads to some central thought directions. They are:

• A central system of configuration,
• A global approach to database back-end with ability to be used by external modules.
• Cross-linking of functions of different products
• Uniformity of functions
• Basic GT functions available in all products.
• Modular design of functions like add-ons Blocks of scripts like Gmail, Gforum and Links SQL.
• Reduce the diversity as much as possible inbetween the products.

The best would be to have a version 3.0 of all products with all common concepts, approaches and uniformity including tables, fields, functions, scripts, libraries, etc!!!