[nvda-addons] Re: Add-on update subsystem: preliminary design - a database back-end in partnership with a client UI
- From: James Scholes <james@xxxxxxxxxxxxx>
- To: nvda-addons@xxxxxxxxxxxxx
- Date: Thu, 28 Jul 2016 23:55:59 +0100
Joseph Lee wrote:
4. Client checks for add-on updates (automatic or manual), using a
dictionary.
A couple of things:
1. Are you thinking about an HTTP GET request per add-on, e.g.:
https://addons.nvaccess.org/update_check.json?addon_id=<addon_id>¤t=1.2.3
(where addon_id is a unique ID for the add-on in question, and current
is the version number the user currently has installed)
Or a single POST request, with the body set to a JSON payload containing
the IDs and currently-installed versions of all the user's add-ons:
POST
https://addons.nvaccess.org/update_check.json
Body:
{"addons":[
{"id": "<addon_id1>", "current": 1.2.3},
{"id": "<addon_id2>", "current": 3.2.1},
...,
]}
Perhaps you could look into how other popular projects e.g. Firefox
implement update checks. Also, how do we mark an add-on as being
installed from the community add-ons site, and not manually by the user?
Presumably, add-ons which have passed basic review and made it onto the
site will have some sort of UUID in their manifest, as above, but how do
we prevent people tampering with these or inadvertently choosing
duplicate IDs?
6. Client chooses an option (if yes, add-on will be downloaded; if
not, the version will be added to “do not ask” list).
I think a third option should be offered here - remind me later. Just
because I don't want to download and install an update right now,
doesn't mean I never want to be prompted again.
· What: among various database packages, we should choose a
robust one that scales to the needs of the add-ons community. Note that
the database must run under Ubuntu, as this is the distro in use.
Not a particularly difficult choice. The data being stored is simple
enough, and the number of requests likely low enough, for any database
to cope with it just fine. You can also utilise caching to minimise
stress on the backend data provider, if this becomes an issue which is
unlikely.
· Scope: Jamie mentioned in issue 3208 that this should be
limited to add-ons posted on our community add-ons website
See above.
--
James Scholes
http://twitter.com/JamesScholes
----------------------------------------------------------------
NVDA add-ons: A list to discuss add-on code enhancements and for reporting
bugs.
Community addons are available from:
http://addons.nvda-project.org
To send a message to the list: nvda-addons@xxxxxxxxxxxxx
To change your list settings/unsubscribe:
//www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
Other related posts:
