Ross, I understand your position - surely backed by more sysadmins. I hope you will understand mine - hopefully backed by someone else. :) En/na Ross Golder ha escrit: > Server-side scripting for a dynamically generated homepage? No, a full featured community management system to generate dynamic content, manage users, create several roles and permissions within the CMS, create and expand forums or galleries or whatever through integrated modules, set up a CRM tool, manage donations, send newsletters and announcements to users wanting them, facilitate p2p communications, and dozens of possibilities more that we could also study. > From a > sysadmin's perspective, if it can be avoided, that'd be great. >From a marketing and communication and community perspective, it can't be avoided. It's not a caprice. We need to convice users our desktop is the best. The website is our main channel to communicate this. Look at our competition: http://www.microsoft.com/windows/default.mspx - http://www.apple.com/macosx/ - http://kde.org/ - http://www.xfce.org/ Their sites are good, we could find improvements but they are far better than ours. Do you think they 'avoid scripting'? Do you think we can have something better that them using static pages and CVS? IMO it's like trying to develop Java applications with gEdit and one finger. You can do it but... why avoiding all your own resources and the great tools that have been developed just to do that? If the concern is the security and performance of bugzilla, cvs... leave a box alone for all the tools you don't trust, and leave us manage them in a way it doesn't harm your sysadmin policies - which I understand, except when they come to avoid "scripts". > If we can > stick to it being statically served by Apache, we can completely avoid a > few potential issues (of load, security, performance etc.). By avoiding completely few potential issues we are favouring completely a potential defeate of the GNOME project trying to attract users nd developers. Why coming here if everything is much cooler in Ubuntu, Fedora or KDE. On the other side, if it's needed I would like to discuss in more depth this issues of load, security and performance. As if all CMS were overloading, unsecure and unnefficient. And as if our current system was exempt of issues, potential or not. > However, I can't see a problem with a server-side script (run hourly All we should understand that the gwo homepage is just the top of a huge iceberg. A dynamic box listing latest news and offering a RSS feed solves nothing. Any solution going through CVS updates solves nothing. Any solution going through static pages solves nothing. Because the problem is not about pages or contents or updates. One problem is that we don't understand that a website is primarly a community tool and not a piece of software, nor a thread to the servers - and a community tool is made by tools to enhance communities. Because of the lack of community tools, another problem is that people who know how to deal with static pages and CVS is investing most of the time working with hardcoded HTML, static layout design and manual content management, while people knowing about content structure, content writing and interface & grafic design are kept away from the website development and maintenance due to a (IMO senseless) technological divide. In the meantime I read Miguel and Havoc's debate about "web aware" GNOME tools able to communicate from the desktop via http and... and I think how schizofrenic is to have such advanced debates while here we are still discussing if it's appropriate to have a script in a web server to serve a web page. I understand Claus when he feels like wasting the time. We need to find a solution that makes happy to marketing + gnome-web + sysadmin, otherwise marketers, webhackers and sysadmins will feel like wasting the time with each other. And some guys will setup lovegnome.org in a weekend and one month later they will achieve what we couldn't in... (I don't know when this debate started). -- Quim Gil - http://desdeamericaconamor.org
Attachment:
signature.asc
Description: OpenPGP digital signature