WebRunner:Planning
WebRunner Spec Ideas
Features that WebRunner could support. Listed from most basic to most advanced.
- Use Firefox 3 as the runtime for the WebRunner application
- Open a bookmarked webapp in a chromeless window (separate process) from a Firefox menu
- Chromeless window should remember size and position for each webapp between sessions
- Install a webapp to the local machine as a launch-able, dock-able, shortcut-able, ALT-TAB-able application
- Favicon used as icon
- Special stub launcher that warns if Firefox was installed, since Firefox will be the runtime
- Enable WebRunner to support regular extensions
- Some extensions would extend the chromeless window
- Some extensions would extend the webapp (google gears)
- Allow some tweaking / scripting of the chromeless window (basic to advanced)
- Add popup alerts (notification of new mail or meetings in gmail, gcalendar or zimbra)
- Allow addition of webapp specific toolbars and menus to the chromeless window
- Allow webapp mashups (meboo / gtalk could be a sidebar in zoho / google apps)
- Add drag-n-drop support (files to google docs or images to flickr)
- Add content handling (register file types with OS so user can double click files to open them in a webapp)
- Allow simple file / DB access - sandboxed to a specific folder in the user's profile
Note: The WebRunner would not add any web-facing API's. Any additional API's would be available to the WebRunner chrome script only.
Discussion
mfinkle: I think (#1 - #3.1) is the minimum basic feature set. However, I think a basic feature set is not rich enough. People are expecting (and asking for) a feature set closer to Adobe AIR which is (#1 - #5.6). Keep in mind that #4 is a freebie since its builtin into XULRunner and #5 is a minimalist API exposed to a greasmonkey-like, sandboxed JS script. We don't need to create all the uses, just the API to enable them. Personally, I'd like to see WebRunner with a feature set somewhere like (#1 - #5.3), although the file handling features (#5.4 & #5.5) would be killer features.
20after4: I would be willing to help implement File handling! I have been writing an XUL App that manages photo galleries. I already have working code to handle dropped images on both the application window and on OS X it handles files dropped on the application's dock icon. I will go to work integrating that into an extension for webrunner. I think that webrunner has enough flexibility that I can now stop writing custom XUL Applications and instead concentrate on .webapp packages and extensions for webrunner.
Bosky101: could webrunner have an inbuilt class library with decent system access documentation. or the ability for webrunner to plug'n'play with js libraries like jquery /dojo that would be great. in particular ,in extending the vector and graphic capabilites like for svg,effects and so on. The reason i point this out is that if you check out adobe flex, the reason they can take it offline,online with such ease and give such a rich nature is because of a bunch of classes theyve built. infact when coding in flex, these classes are not even closed - it's just there ,coded up nicely and available. i think webrunner needs an inbuilt bunch of js classes OR atleast the ability to plug-in js libraries which can then be accessed specifically for webrunner apps.
20after4: I don't think it would be difficult to include some JS Libraries like Bosky suggests. It might not make sense, however, to bundle them with webrunner. There are so many to choose from that it would be impossible to satisfy every developer without including several libraries, if that happened then maintaining and updating the 3rd party code would become an issue. I really doubt that the lack of a built in high-level api will be a problem. One of the best features of Mozilla's platform is the rich extensibility that is provided through chrome extensions and I think that will alleviate the need for extensive built in libraries. I do think that there should be some webrunner-specific APIs (perhaps borrowed from fuel) which could make webrunner into a respectable development platform in it's own right. With a few common APIs covered (in a mostly Firefox-compatible way) then individual apps can install their own JavaScript libraries or share a library that is installed as a webrunner extension.
I would also like to comment on a slightly related topic: Many Firefox extensions are fully featured applications that simply deploy on top of the Mozilla platform and use Firefox as their runtime. With the news of Firefox deploying a reusable runtime I think that some of these extensions could (and should) be moved into webrunner. I love Firefox, don't get me wrong, but it's not the right place for some of the extensions that I have seen (and some that I use.) The more elaborate extensions that I install the more problems I have with Firefox stability and memory consumption. In the not-rare-enough occasion that Firefox crashes, it takes several applications with it because they run in-process with the browser. For simple browser features, regular extensions make since. For more complex application behavior I think we should be using webrunner or totally custom xul applications instead. For this reason I think that something like fuel should be encouraged and utilized even outside of Firefox. A common api could create an easy path to port an extension into a stand-alone app - at lease for the extensions that simply install a button in the browser which then launches the app into a mostly stand-alone window.
20after4: I would like to suggest that the profile.js file be modified to allow for arbitrary profile keys to be used. I am adding features by way of an extension and I am forced to patch profile.js in order to add my own custom webapp.ini settings. The profile.js parser has a preset list of allowed parameter keys and no new ones can be accessed without modification to that file. I can submit a patch to make this change if it would be acceptable. Update: I have submitted a feature request (and implementation!) in BugZilla bug 395548
