Spring cleaning 2012

Spring is in the air & it's time to do some cleanup! There is bunch of stuff in SDK that was there for a long time from little to no advantage to the users. Some of this stuff has being replaced with a better alternatives and some is not really compliant with our long term goals. Here is a list of things that fall into that group:

1. exports.main

This feature is currently documented under Listening for Load and Unload tutorial of the SDK. This feature allows authors to write an entry point main function that is called on add-on startup, with several arguments that can be used to do different things:

#!/bin/javascript
// called at startup
exports.main = function (options, callbacks) {
  options.loadReason // describing the reason your add-on was loaded
  options.staticArgs // data passed as `cfx --static-args` 
  
  callbacks.print 	// prints to output
  callbacks.quit	// quits application
};

// called at shutdown
exports.onUnload(reason) {
  reason 			// describing the reason your add-on was unloaded
};

Now most of this can be replaced with already provided functionality:

• options.loadReason:require('@packaging').loadReason ?? need something better
• ptions.staticArgs: This is no way an API for add-on's as users are not going to run cfx run, on the other hands it adds complexity for no benefit. In addition this can be accessed via require('api-utils/system').staticArgs. Most likely we'll deprecate that some time in a future as well.
• callbacks.print: This is redurant function as you already have console.log
• callbacks.quit: This is again not really useful for add-on's, specially in this forme. Also, there is more preferable laternatvie require('api-utils/system').exit().
• exports.onUnload: There is require('api-utils/unload').when(f) for that, which is more preferable.

Removing this arguably useful features would allow us to start add-ons faster, as we'll have to do load less code. That way only add-on's that depend on this functionality will have to pay tax and load bit's of useful functionality manually.

2. data & self

At the moment self module behavior in relation to data folder is somewhat magical. What I means is that if you happen to have another foo package in your packages folder that your add-on bar depends upon. modules form from bar will get different result when calling require('self') from modules of foo. Not only module will be different but also a data folder it is associates with. In a near future we plan to build a good system for module sharing module sharing without any need of packages. There for this feature will be deprecated. Also in a future we will deprecate self module used mainly for require('self').data.url('./index.html') in favor of just './data/index.html'.