The Future of CCK2

This involves removing any dependencies on the distribution/bundles directory as well as rewriting the code to no longer use XUL overlays.

As I’m doing this work, it has me wondering; should the CCK2 be a library that you simply pass a config to and it does the work (as it is today), or should the CCK2 Wizard generate a complete AutoConfig.js file that stands alone and can be included with little or no other outside files?

In doing surveys in the past, there are quite a few people that just use AutoConfig. Would it be worthwhile to make the process of generating AutoConfig files easier? Or is this a very small group of people?

Whatever is easiest for autoupdate-ability. I need to be able to push out config changes to users without having the users install a package. This is why the extension has always been appealing to me. Extensions are designed for autoupdate and can poll for changes from my web server. In that sense, the library seems most logical to me.

I’m open to whatever I can deploy. However understanding how malware can manipulate these standalone settings, I’m on board with whatever it takes. We are currently relying on standard user permissions to protect these flat file settings.

We depend on smooth deployments with nearly zero user intervention in starting Firefox up for the first time. But we also need to be flexible with our web devels to allow settings to be changed, but, it’s not critical.

I never grasped extension deployment so I took the easy road with autoconfig.

Super work Mike! It’s wonderful having someone like you pulling for us.

I believe Mr. Kaply is not permitted to make the CCK2 code a part of the core Mozilla codebase, because the people in charge simply do not want it. This is consistent with the other times Firefox removed tools that enterprises used, without comprehensive replacements. It just isn’t a high priority, it seems. This is how it looks from the outside. I have no idea what discussions are going on within. I could be entirely wrong about everything.

Thus, it’s always fallen to Mr. Kaply and others to pick up the slack, and they’re not making his job easier. Firefox is my favorite browser for personal use, and will probably remain so indefinitely.

And to the important bit: generating a complete autoconfig.js would still meet the majority of my needs, thanks. In the long run, it’s simpler and more likely to remain supported and improved. So, it could be easier AND very thoroughly documented for more advanced users.

It seems increasingly obvious that Mozilla is managed by people with dubious decision making credibility. How can they reasonably expect to maintain any sort of market share on the desktop without decent enterprise deployment support? Morose! Chrome and IE kill Firefox in this respect with their support for Group Policy. It’s astounding that Mozilla makes so many poor decisions. First they delayed fixing the awful memory management issues in Firefox, then there’s still the lack of multi-process (excepting plugins) as that’s taking forever to implement, then there’s rapid release which apart from anything else results in incredibly underwhelming media reviews for each ‘release’.

Seems if it’s not Firefox OS related, there’s no direction from management. Desktop Firefox is just in a holding pattern.

I think which over option gives the most flexibility I guess is best. We are currently using an autoconfig with a mixture of CCK2 settings and direct Firefox settings. Add to this user profiles so different sets of users get different settings, so we have a base config var for CCK2 and merge in changes like allowing access to about:config for select IT staff.

As always great work Mike! One day Mozilla might just think about all the enterprise admins out there tearing their hair out 🙂