Hi, Am 13.01.2014 01:34, Mike Hommey wrote: > Let's face it: xulrunner is hardly maintained, we barely build and test > it on automation, and the result is that it is often broken for long > periods of time. > > I propose that we just stop pretending, and terminate xulrunner, > considering the following:
Thanks Mike for getting this topic started, even though I kind of settled very well with the status quo and was hoping sleeping dogs would not be woken up :-) But it had to happen at some point, so let's make sure we come out of this whole discussion with a better solution than we have right now. I totally agree with Mark that the lession we've learned in the past is clear: Am 14.01.2014 15:16, Mark Finkle wrote: > We've know something for a long time: If Mozilla is not using a > tech/project in Firefox, support for the tech/project will wither. My use case is kind of a typical XULRunner-based application. I have custom application code and distribute a private (self-build, unpatched but localized) XULRunner copy with it. It runs on Windows and Linux. I don't see any problems with using a custom copy of Firefox instead of XULRunner for my use case at first sight. > - Since bug 755724, running firefox -app application.ini is 99% the same > as running xulrunner application.ini, except for a few details that > should be considered bugs. Before that bug, it was quite different, > as browser-specific files were available to the xul application. sounds good, even though I don't get the whole story in bug 755724, the discussion there is rather extensive :-) > - There is no reason we can't generate the sdk from firefox instead of > xulrunner. Moreover that would make firefox-specific interfaces > available in the sdk that aren't currently (which may or may not be a > good thing, arguably) If the application doesn't need to use it I don't see any problem with it. > - We could include the xulrunner and xulrunner-stub executables as part > of firefox. xulrunner-stub is small and self-contained, and xulrunner > could be replaced by something that calls firefox -app. Or we could > make the firefox executable check under what name it's called and act > accordingly. The functionality of xulrunner-stub is really nice and I'd be glad if it could be retained. To me making Firefox check under which name it was called and act then like xulrunner-stub sounds like the solution which has the largest chance of staying supported. I'm volunteering to help out with patches here if it is clear which way we want to go. The simplest solution probably would be to just keep the xulrunner-stub code as it is somewhere, maybe behind a ./configure option, for those people who need it. Another thing that kind of comes together with xulrunner-stub is the redit.exe tool (in xulrunner/tools/redit) to replace the icon of an EXE file. Again, it would be nice if it could stay in the tree somewhere, but otherwise I'd just take it to some github repo and be fine with it. Since it seems that all other parts that I need are there already I'll give this whole thing a try next week and report back how things go. An open question right now would be how the updater will handle things. As a closing remark, since this discussion is not prompted by any immediate problem with XULRunner from what I understand, I'd be happy if things could stay the way they are until we come up with some alternatives or decide that a particular problem will have no alternative solution. Just don't rip out the code as first step :-) Philipp _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
