Extension Manager:API Rewrite: Difference between revisions

Extension Manager:API Rewrite (view source)

Revision as of 17:34, 13 October 2009

1,314 bytes removed , 13 October 2009

→‎Addon

Mossop

canmove, Confirmed users

1,570

edits

@@ Line 15: / Line 15: @@
 ==Addon==
-The [[Extension Manager:API Rewrite:API#Addon|Addon]] object represents an add-on that is installed on the local system. This is a loose term since it also includes add-ons that have been downloaded and will be installed when the application is restarted. It is likely that the API will hand out multiple instances of Addon for the same underlying add-on since the alternative right now would involve caching each Addon for the lifetime of the application. The only way around this would be to add some form of weak reference support to JS. There are a set of properties that will be available for all types of add-ons and then each type of add-on may have additional properties. The same goes for operations that can be performed on the add-on.
+The [[Extension Manager:API Rewrite:API#Addon|Addon]] object represents an add-on that is installed on the local system. This is a loose term since it also includes add-ons that have been downloaded and will be installed when the application is restarted. It is possible that the API will hand out multiple instances of Addon for the same underlying add-on. There are a set of properties that will be available for all types of add-ons and then each type of add-on may have additional properties. The same goes for operations that can be performed on the add-on.
 Certain add-ons may have restrictions over what operations can be performed. These restrictions could be just down to the nature of the add-on (themes cannot be disabled normally) or down to system policies (user's may not have access to uninstall some add-ons f.e.). Each Addon has a permissions property that indicates what operations can currently be performed.
@@ Line 21: / Line 21: @@
 Some types of add-ons may require restarts for certain operations. XPI style extensions for example require restarts for almost all operations. The API exposes the operations that are pending in the pendingOperations property. It is also possible that this property may be used to indicate operations that have been deferred for any reason, maybe timing issues, maybe a dependency is pending install. Pending operations can make it hard to tell what state an actual add-on is in. To help solve this the isActive property indicates whether the add-on is currently active. This is separate to and may be different to the various userDisabled, isCompatible and other properties that indicate whether an add-on can be active or not.
-''It is currently undecided whether Addon objects are truly live views or not. There are a few options with pros and cons''
+Addon objects are live views of the underlying add-on. The properties are always guaranteed to be up to date.
-;Totally live :Here the Addon object's properties are always guaranteed to be up to date. There are really only two ways to do this, either a property access ends up as a database query or we cache every Addon object retrieved through the API and make sure that is up to date. The former is a problem since we want to avoid synchronous database queries and making all property accesses asynch would be wrong. The latter is a potential memory concern perhaps mitigated if we could get some weak reference support into JS.
-;Single instance live :Here if you perform an operation on an instance of Addon then that instance will have its properties updated. Any other cached instances of Addon that are representing the same add-on would not get updated though. This is potentially confusing for obvious reasons, but maybe not terrible. A general rule of recommending people not keep instances cached anywhere would seem to solve it.
-;Never live :Here the Addon's properties are fixed at time of retrieval and never update. It is perhaps less confusing that the previous option but ultimately less useful too I think.
 ==AddonInstall==