Gossamer Forum
Home : Gossamer Threads Inc. : Discussion :

Products differences Links SQL, Gmail and GForum!

Quote Reply
Products differences Links SQL, Gmail and GForum!
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!!!

Last edited by:

rajani: Oct 8, 2002, 2:50 AM
Quote Reply
Re: [rajani] Products differences Links SQL, Gmail and GForum! In reply to
Quote:
Different methods of password storage / encryption: Only Forum offers encryption but Gmail and Links SQL not.

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.[/code]
Products like Links SQL need un-encrypted passwords to use the simple password retrieval function. I guess as time goes by the staff think of new ways to get around this such as creating temporary passwords in GForum.

Quote:
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.

How do you mean?....you can have as many modules as you want with the same name as long as they are in different directories. As a programmer it is important to keep the code clear as well as the module layout. Sometimes it is necessary to name the modules in this way to identify their purpose easily. An example of this is with Plugins.pm .....GT/Plugins.pm is the core module - as is everything inside the GT directory. GForum/Plugins.pm is the user module used for retrieving plugin configuration options. Naming the modules the same gives a clear indication of what it does - ie one has the core functions and the other has the user side functions.

Quote:
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.

Which concept didn't work?.....There is one globals file per template set which adds flexibility and I really like that. Having one globals file pers product is reducing flexibility.

Quote:
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.

This can be done simply using include tags. I presume the template parser supports paths in include tags so you just need to put all your includes into a central directory and then do:

<%include /path/to/include%>

Quote:
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.

Maybe I'm speaking from my own perspective as someone who uses the template system more than others but I don't see this as a problem as it is. Moving everything into a config file would again reduce flexibility. The template system is there to do cool things like call module functions with a tag and not to limit features by moving stuff out of the templates.

How were you envisioning the auto-insertion?

Quote:
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!).

I'm not too sure what you mean there. Mysqlman does allow you to connect to a remote mysql server....I use that feature myself sometimes.

Quote:
Path to perl: This is possible only in Links SQL and not in other products.

Are you sure?.....it is there in GForum.

Quote:
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.

Jason has said there will be no control panel for GForum version 2 so that may not be a fruitful task :)

Last edited by:

Paul: Oct 8, 2002, 4:30 AM
Quote Reply
Re: [rajani] Products differences Links SQL, Gmail and GForum! In reply to
Hi,

Wow, that's quite the list. I'll try and answer some of your points briefly:

1. Links SQL will move towards encrypted passwords. Gossamer Mail won't as they are often required for authentication via POP server (where the password must be sent in plain text due to the POP3 protocol).

2. The lost password options depend on how the passwords are stored. Community will provide a central login/signup/lost password features for all products.

3,4: We are constantly looking at how to improve the admin layout to make it more user friendly. One of the things we are exploring is removing the framed interface, and also moving the admin into the user side.

5: We may look at framing things with a top level admin, but I don't see us doing any tighter integration then that.

6: Doubtful we will do this, as a library change could break older products and may slow down releases of updates until all products have been updated (as then you couldn't install the latest Gossamer Forum until we came out with a Links SQL upgrade for instance).

7. I think you mean files, not modules, as the modules are all named separately (and have to be so things can live happily under mod_perl).

10: Common represents a template set that other template sets inherit from and is different then default.

11,12: Paul answered these pretty well.

14: You can change this after you install. Currently the installed checks to make sure the fileman directory is writeable.

15: No, it wouldn't work. Gossamer Forum installer does not give you the option for a separate admin path. If you do it manually, then it's going to make upgrades quite hard.

16: This is an issue with MySQL. The LOAD DATA/SELECT INTO work only with a file on the SQL server.

18: This is needed only in Links SQL, not in the others (required for the parallel link checker to work on windows)

19: Same as 5

20: The tables have been designed (especially in the case of Gossamer Forum), for maximum performance. I don't see why anyone familiar with SQL would not have an easy time pulling user information out of the database. The MailArc plugin has a simple example of how to add a user from another program.

21: Community will provide a solution to this.

22: Different products have different needs for what path's and URL's they ask for.

25: We will be offering a solution for this soon.

Cheers,

Alex
--
Gossamer Threads Inc.