Hi!
I really like the way how comm_ and the prof_ prefixes are designed.
What I am afraid is that in the upcoming Architecture of community, there are two different prefixes within one table. This is on one side great, as it gives a potential of handling system fields and user defined fields, on the other side it will give great difficulties to the people who may want to use and share the User_table with other applications.
I do not know how much work it may require to have a defined prefix in there like a $system_prefix (= comm_) and $user_prefix (= prof_) everywhere in the distribution! Then this may be defined like table prefix in the database.def !!! Later a user could define what should be the prefix in the users table during the installation. Or atleast I do not know how this can be implemented.
The greatest advantage of this is all the fields will be available to all the other applications other than GT applications. For e.g. I want to share the Users table which is LIVE with Postnuke:
- This has a $prefix_users and all the fields exactly similar to Community and they all begin with pn_fieldname.
- Users table is one of the most important one and working with it a shared table with other application is - FOR ME - most important.
- At the same time a common authentication is equally important.
To achieve this, People may need to convert comm_ = prof_ = pn_ <% for instance %> OR all = gt_ in the users table. Making a counter argument,
If a webmaster having a database with 250.000 users in the table using postnuke or phpnuke or phpwebsite. They all have the same Architecture _more_or_less_ genrally speaking. He will have problems to use community because there are two different prefixes for GT products in the same users table. He already has a table ready but cannot use the GT applications with the postnuke/phpnuke live site without major modifications in the GT community.
I beleive GT Community should really cover many such issues also that opens a new door for all the existing users of the GT community to start using other applications on one side, and on the other side, invite other communities like phpnuke/postnuke to invite to use GT applications. Like opening doors to 30.000 users of the dynamic contents like such CMS sudenly offering all the GT products to them!
The concept of community is like a central passport and hence needs to cover such challenges too. Those were my ideas.......
I fail to beleive that this application will not be popular on the internet. I expect thousands of downloads the moment it comes in the directories everywhere. So a free product like community has a terrific potential of sale of other GT products to other CMS communities tiying other communities togather........