Talk:Firefox3/PRD: Difference between revisions

Talk:Firefox3/PRD (view source)

Revision as of 05:38, 7 March 2007

2,768 bytes added , 7 March 2007

Corporate installer and centralized configuration

Stumppc

1

edit

@@ Line 346: / Line 346: @@
 == 64bit builds ==
 -bit CPUs for end users are a reality. It'd be a shame if firefox 3.0 didn't support a rock solid 64 bit experience. Even OO.org supports it! Right now there are issues...(https://bugzilla.mozilla.org/show_bug.cgi?id=237202)
+== Corporate installer and centralized configuration ==
+== Without a comprehensive, friendly,and well-documented unattended install and management system Firefox will never see widespread use and distribution in the corporate world. ==
+Here are some thoughts to help address these issues:
+I would like to suggest that the developers working on Firefox 3 put a lot of emphasis on creating a good method for automated installs and upgrades. With Firefox 2.0.0.x right now the installer packaging is part of the build process. Administrators trying to make their own customized installs have to do a lot of work to learn NCIS, modify the install script, and then build their own version. The installer packaging needs to be separate from the build process and allow post-build customization much like prior versions of Mozilla and Firefox.
+I have seen a lot of implementations using .msi installers and group policy templates for the Windows build. FrontMotion has done some great work along these lines - please see http://www.frontmotion.com/Firefox/fmfirefox.htm for details. I think a more vendor-neutral solution to the corporate-type install should be in order given Firefox's cross-platform heritage. Many companies have multiple OS types to support now, so why not take a different route from Microsoft's preferred method?
+I would like to see an official Mozilla re-packaging tool that could include add-ons, updated files, and additional files to official releases.
+Along the central management line I would like to have a GUI utility that configured every feature that could be centrally managed. The GUI would create a config file that could be placed on a web server or file system. The packaging tool would provide a way to define the location of the config file. Custom configurations for different users/groups could be accomplished by adding some variable determiners to the config GUI and config file. The configuration file could key some features off user, group membership, computer name, etc. It should be a config file with the possibility of multiple configurations nested in it, especially if this config file is to be hosted on a file system. Config files hosted on a web server could use CGI scripts, etc. to serve up a custom configuration file.
+Most (if not all) of the underlying functionality for automated installs and centralized management is already built-in to Firefox. It has never been comprehensively embraced with tools that would make it easy for network admins to take control of Firefox and deploy it in their organizations. Why should administrators keep reinventing the wheel by creating their own installers and install methods when simple tools could be created and reused by everyone?
+Thanks for reading my rant...