CCK:Overview
I'd like to use this page to try to foster some Client Customization Kit (CCK) discussion.
I'm looking to revive the CCK.
Here's some info:
So basically, there were two products from Netscape, one from the old 4.x days called Mission Control Desktop, and one from Netscape 7 called CCK (actually MCD renamed, I'm simplifying here)
The MCD product provided an interface to lockdown preferences, as well as the CCK functionality. It was written in Java.
MCD was released as a replacement for the 4.x CCK.
so it went CCK->MCD->CCK
From the FAQ at:
http://wp.netscape.com/partners/distribution/custom/faq.html
What is the difference between the CCK and Netscape Mission Control Desktop?
The CCK and Mission Control Desktop have similar underlying software but substantially different end-user license agreements. Although the CCK is an excellent tool for ISPs and Internet content providers, it does not allow for centralized administration of the browsers, nor does it provide the centralized software distribution tools available with Mission Control Desktop. In addition, the CCK has more restrictions on what preferences can be customized
Here are some old web pages about MCD:
- http://wp.netscape.com/communicator/missioncontrol/v4.0/
- http://wp.netscape.com/communicator/missioncontrol/v4.5/
The original 4.x CCK is here:
The Netscape 7 CCK focused on a customized install. This customized install included things like home page, throbber, throbber icon, help menu, bundling XPIs into the install, etc.
If anyone would like to see the CCK, it can be downloaded here:
ftp://ftp.netscape.com/pub/cck/english/7.0/NSCCKSetup.exe
Currently, it is Windows only.
There is CCK code in the tree, but I'm not sure it is a good place to start. It is here:
http://lxr.mozilla.org/mozilla/source/cck/
Anyone have any suggestions as to how to create a cross platform install packager/customizer app?
What is more important to people, a good interface to lock down preferences or a customized install?
Should we look at creating a XUL runner app?
Or should it be an extension to Mozilla/Firefox/Thunderbird?
--Robin Lu-4/28 10:29:53 CST 2005
We made an MCD like tool before with Java. It contained two componnents. One is Installer Builder to build a customized installation package. The other is Configuration Editor to generate autoconfig.jsc and encoded .cfg file for centralized management of preferences (including locking). However, the project was canceled for business reason at last although we have already got a workable product for Mozilla 1.2 and Mozilla 1.4.
We chose Java because at that time xul application was not as easy to make as today. Now it is a good choice to build the installer builder as a XUL app. In the fontend, we can collect customizing information and generate script like this: http://lxr.mozilla.org/mozilla/source/cck/ib/script_Windows.ib In the backend, we can either use native xpcom or native package builder to generate installer packages for different platform for different needs. It is very flexible. Our Installer Builder for Mozilla was able to generate RMP(linux only), tar.gz and Mozilla installer package for both Linux and Solaris. Though we haven't tested, it could be easy to generate installer package on Windows too.
For centralized management, autoconfig still works for Firefox/Thunderbird/Mozilla. We can build a tool like the configuration editor in MCD as we did before, but I think to make a web application is more convinient. By using configuration editor, you have to generate the autoconfig.jsc locally and deploy it to the central server. If we build a web application, admin can maintain the configuration directly on the central server.
--MikeKaply 08:38, 28 Apr 2005 (PDT) Was there any effort made in the beginning to move some of the CCK specific changes into preferences, or was it always assumed that DTD/properties files would be modified?
--Robin Lu-4/29 09:38:01 CST 2005 No. Some changes have to be in DTD/properties files for l10n reason.
Can we divide CCK to two components? One cares about the default settings. Installer package builder is for that. A lot of changes can be made here, including preferences, DTD/properties, bookmarks, icons, RDF and more. The other cares about managing. MCD had both of the components while Netscape CCK only has the first one - installer builder.
Right now, only preferences can be managed. Although we can use extension but it highly depends on the users, which is not a good way for management. What do you think should be managed besides preferences?
--MikeKaply 06:47, 29 Apr 2005 (PDT) I definitely thing two components is the way to go, and I like your web management idea a lot.
The only other thing I think someone might want to do is remove/disable menuitems as well as preferences for a corporate lockdown (or about:config for instnace)
So you are correct, one focuses on being very to the CCK, and one focuses on locked preferences and possibly locking other things.
And perhaps we can make the install piece use a mozilla.cfg file if it is available to combine the two (not just putting the jsc file on a server)
--Robin Lu 4/30 10:21:50 CST 2005 You are right. The mozilla.cfg should be added into install package by installer builder to enable the autoconfig by default. It is the connection point.
For the menu lockdown, we should find out if admin want to lock the menu by default or they want to manage/change what to lock after deployment. I believe locking the menu by installer builder can meet most of the requirement. "Lock" is not the reason for it in management component. With installer builder, you can also lock some preferences by default. Management is about "change". What do you think?
--Robert O'Callahan Just so you know ... Novell is working on code to use the gconf system pref service http://lxr.mozilla.org/mozilla/source/extensions/pref/system-pref/src/gconf/nsSystemPrefService.cpp. to lock prefs. gconf already supports "read only" system preferences that can't be overridden by users. We want to extend this support to the gconf system pref service so that the Mozilla pref is locked when the gconf pref is read-only. (Right now the way we do this is terrible, I need to fix it up.)
