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
