[nvda-addons] Re: Add-on update subsystem: preliminary design - a database back-end in partnership with a client UI
- From: "Joseph Lee" <joseph.lee22590@xxxxxxxxx>
- To: <nvda-addons@xxxxxxxxxxxxx>
- Date: Thu, 28 Jul 2016 16:21:02 -0700
Hi,
Jamie knows more about this, but:
* Overall transport package: Not sure if it's going to be JSON (likely, but not
sure).
* Dictionary keys: At least the internal add-on name (the internal identifier),
version and the key that says the name of the file to "upgrade" to (if it
exists).
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of James Scholes
Sent: Thursday, July 28, 2016 3:56 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Add-on update subsystem: preliminary design - a
database back-end in partnership with a client UI
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
----------------------------------------------------------------
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:
