Hi Alex, I am a maintainer of the geckofx[1] project, which the organization I work for makes use of in a number of applications. As I understand it, the proposal to "Terminate xulrunner" is just about removing the xulrunner.exe and having firefox.exe assume that role. However given the mention of a "Firefox SDK" and although its not entirely clear to me what this will be I thought this would be a good opportunity to state our firefox requirements. (Apologies if this is not the sort of thing you are after)
* Being able to embed firefox in existing applications. (Currently done via passing win32 or gtk window handles into nsIBaseWindow::InitWindow()) * Being able to interact with firefox via C# (Currently done via XPCOM and PInvoking exported dll methods - allows implementing IDL interfaces in C# and having firefox use them.) * Being able to invoke arbitrary javascript from C#, including setting the 'this' context (Currently done by pinvoking mozjs methods) * Being able to respond to events and manipulate the DOM via C#. Generally the embedding using XPCOM approach has worked very well, however a number of things made it harder to use Firefox in a non C++ application: * Removal of the C ABI from mozjs. (C++ ABI are harder to use from non C++ programming languages) * Some IDL methods can only be called from C++ (eg: in FF15 nsIThreadJSContextStack::SafeJSContext was changed from an attribute to be implemented as a 'virtual' method, which prevented it from being called via non C++ COM clients) * WebIDL (At least I'm not aware of a way for non C++/JS languages to use WebIDL objects, in the way your can with IDL objects) I'm mentioning these things in order to suggest a requirement that any "Firefox SDK" be easily usable in languages other than C++ and JS. Thanks Tom Hindle Software Developer, SIL [1] http://bitbucket.org/geckofx/ - (GeckoFx is a C# library that allows embedding Firefox into a C# winforms application. - interaction with firefox is done mainly using the XPCom interfaces.) On Thursday, February 6, 2014 12:08:45 AM UTC-7, ajvi...@gmail.com wrote: > Hi, everyone. There's general consensus that we want to terminate XULRunner > as a project and replace it with a Firefox Platform SDK (name to be > determined). [1] However, what precisely we want that SDK to do, and to > support, we haven't figured out yet. > > > > I recently submitted a bug and patch to copy the stub executable and > application bundling script (install_app.py) from XULRunner to Firefox. Mike > Hommey (glandium) thinks that's a bad idea. [2] His objection is that "that > just makes it stay outdated each time browser/app/nsBrowserApp.cpp is > changed, which is one of the many reasons we want to get rid of xulrunner." > > > > Okay, fine. I'm all in favor of doing things the right way instead of the > fast, hacky way. I'm also willing (and with my bosses' backing, somewhat > able) to put in the time necessary to implement the right way. Getting > XULRunner into an actually-usable state took a lot of hacks anyway... So we > have to figure out what we really want. > > > > What I propose is writing our Firefox Platform SDK requirements down. [3] > I'll put a first draft together as soon as practical (probably this weekend > or next). First, a "Where Do We Stand" section, expressing what we currently > have, what SDK and XULRunner customers currently try to do and demand from > the Platform SDK, and operating-system-specific issues we face. > > > > Second, a list of concise "What The Platform SDK Must Or Should Support" > sentences to clearly define our requirements. > > > > Third, a "Owners' Vote" section where a group of contributors vote yea or nay > on the second section as it stands on the date they last read it. Specific > objections and commentary may be written afterward. Also, constructive edits > anywhere in the document (in particular, clarifying requirements or adding > important requirements that I missed) are welcome. The idea is to arrive at > a clear consensus on requirements. > > > > Finally, while I want to get this done and done right, I don't want to spend > an inordinate amount of time on getting the requirements done. External > parties want a Firefox Platform SDK yesterday. Firefox 30 development just > started on mozilla-central. I'd like to have these requirements drafted and > finalized before Firefox 31 development starts. That gives us six weeks from > now. [4] I think that's reasonable for a requirements document. > > > > As for delivery dates on the actual Firefox Platform SDK: I don't know. I > had hoped to put the pieces together before Firefox 31 entered the Aurora > channel, so that it could be part of the "extended service release" for the > 2014-2015 year. Until we can clarify what we want, though, that's just a > dream. We can't really estimate the work, and how long it'll take, until we > have the requirements hammered out. > > > > Again, folks: I'm willing and able to put in the time to make this work. > Not just for my prototype XML editor project, either: the company I work for > has a vested interest in XULRunner and in upgrading our platform. This is > important, and shouldn't be rushed... but it should be done as promptly as is > practical. > > > > Alex Vincent > > software engineer, FileThis, Inc. > > author, Verbosio XML Editor prototype > > > > [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/o99wQZBjIJw > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=961936 > > [3] https://etherpad.mozilla.org/s5jInveqm5 > > [4] https://wiki.mozilla.org/RapidRelease/Calendar _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
