Since there is no way to install Talkbalk with the current win32-installer there should be a "talkback XPI install" available so it would be easy to add Talkbalk to my win32 mozilla installation after running the win32-installer. The link to the talkback "zippy" could be on the release note page.
I don't know if we have the legal authority to do that or not. cc'ing leaf and shiva.
We have the license to distribute talkback binaries ( binaries and master.ini only) to install after the Netscape/Mozilla products is installed. This is just to enable Netscape/Mozilla products to send the talkback back to us. CCin chofmann and jpatel.
chofmann has said this was OK in mail. It is only slightly different from including talkback in the zip archives (which we do) or having talkback available on the Netcenter SmartUpdate page (which we will). This particular package would only install talkback into Mozilla/Netscape 6
so we're talking about a separate talkback.xpi for win32 that will be created every day, otherwise we won't be able to ensure the correct master.ini gets included for each build. is this going to be in place of the mozilla-win32-talkback.zip file or in addition to?
talkback.xpi should be seperate from mozilla-win32-talkback.zip. Not everybody submits talkback incidents. It will be very difficult to convince use to install talkback binaries after they install mozilla builds.
the talkback.xpi that gets created as a part of the netscape process (which was formerly known as fullcircle.xpi) i have always used in the creation of the mozilla-win32-talkback.zip file. So, we're creating the talkback.xpi file already; so is this bug just asking to put it up on mozilla.org in addition to the .zip file?
Yeah, I guess we need a win-xpi directory parallel to the linux-xpi directory. And in addition a link to the day's talkback.xpi where the installer and zip archives themselves are linked so people can find it easily.
I believe Dawn set up the MIME types correctly on the mozilla.org server, at least they work on the ftp server. With the correct MIME type a simple link works fine.
"works fine" meaning it launches XPInstall automatically. I agree asking people to unzip would be unkind.
I know this is valuable bug system data space i'm using, but i have to say this for posterity: That rules!
It sure would be nice for either the installer or the zip version, or a whole new version, to only have the browser and core xpi's in it, and if you want more, you can get what you want. I know Linux can do this, I think, but windows cannot, due to the fact that the netzip doodad in the commercial installer cannot be released. So, to get around this, just have a build that has the core things you need to be able to get the XPI's using the client. It would be ideal to have just one skin included, the files in core.xpi, and the files in browser.xpi, so that download size is kept to a minimum. Just a thought...
What would be more likely to happen would be to expose all the individual XPI files we create and then have an update.html page that gives people check-boxes to update only the parts they want. More likely because we already have the pieces and would just need to upload them. The other alternative would be a small open-source MPL-compatible ftp agent that we can plug into the mozilla version instead of using Netscape's dealie. But that's more work to find and integrate.
leaf, dveditz: This is a cool idea. What happened to it? :-) Gerv
I agree, we really want to do this. Soon the Mozilla installer will have a download agent and can be distributed in component pieces the way N6 is, so people can grab just the bits they want. Once this is done a separate talkback.xpi should just fall out of it. Nominating so I don't forget the minor script changes required. I'll hope for 0.8, but I'm aiming at 0.9
When is soon? Download agent for mozilla, what bug number...?
bug 63835 is a good place to start for porting the download agent.
see also bug 38923 for including talkback in mac and win32 installer builds
bug 67764 covers the stub installer for win32
I'm closing this in favor of bug 67764. The script changes have long been done on the install side, it's just up to release to push the results. *** This bug has been marked as a duplicate of 67764 ***