On 1/14/2014 12:34 PM, mka...@gmail.com wrote:
I have a couple concerns.

1. It makes it much more difficult to ship a site specific browser that can be installed 
alongside Firefox (especially if that browser might need to be different than the 
installed Firefox, like based on the ESR). It would seem that the best method would be to 
take a firefox install, remove any bits that are "Firefox" and install that. 
I'm not sure legal would like that.

2. It creates licensing issues. Previously, we would ship XULRunner and there 
were no Firefox trademarks involved. If we are shipping actual Firefox with 
modifications for our application, I would assume it would have to go through 
Firefox legal.
You could build and ship exactly what you need. You could keep building XULRunner builds yourself, or do generic-branding builds of Firefox. Or do a repack to remove the Firefox-specific files from a Firefox install. Certainly without branding issues it's not a problem anyway, right?

I would never recommend using a shared Firefox install for other apps, just as I removed support for a shared XULRunner instance long ago. You should always ship the files you need directly.

How will updating work?

If you are running an app with application.ini, it's not going to get it's 
updates through the Firefox update service, even though you have Firefox 
installed.

So you'll have to somehow rebundle Firefox with your application and send that 
as an update?
Update has always been up to the app developer; we have never had an auto-update system for XULRunner or XR-based apps. You'd create your update packages, set an update server URL in your app, and do all that yourself.

--BDS

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to