Ability to automatically update add-ons

[nvaccessAuto]

Reported by nvdakor on 2013-05-08 07:08 Hi, With the launch of the official NvDA add-ons page at addons.nvda-project.org, it became easier to search add-ons from one central location. Although this helps with downloading add-ons for the first time, a user who is running an add-on may find that he or she is running an older version of an add-on. So just like automatic NVDA update feature, there could be a feature where newer versions of add-ons would be downloaded automatically and prompt the user to install it without having to visit the addons site. Thanks. Blocking #4762

[nvaccessAuto]

Comment 1 by blindbhavya on 2014-09-07 08:27 This proposal would be very useful if implemented. Could you (the devs James Sir) share your thoughts on this?

[nvaccessAuto]

Comment 3 by bhavyashah on 2015-01-01 07:44 Hi, Please add #4762 to 'blocking'.

[nvaccessAuto]

Comment 5 by fastfinge on 2015-02-19 16:17 As far as I know, we haven't yet had security issues with an addon. But I'm wondering what the security implications of people running out-of-date addons are? Especially as NVDA needs administrator access. This is another reason why, personally, I think having the ability to check for addon updates from within NVDA is kind of important. Even if the addon itself could specify a URL to check for updates, rather than forcing everything through the centralized NVDA addon website, that might be enough to get people updating old addons when, not if, a serious security hole in an addon is discovered. In it's simplest form, it could be a file with a version number, download URL, and file hash. I don't think addons are currently signed via any kind of private key system at the moment, and I'm not sure they urgently need to be. Maybe this isn't a big deal, though, if addons are sandboxed in some way I don't know about?

[nvaccessAuto]

Comment 6 by jteh on 2015-02-20 01:17 First and most important, NVDA does not require administrator access. You should absolutely not be running NVDA with administrator privileges. You also should not disable UAC.

For what it's worth, no one is disputing that add-on updates would be nice. It's just a matter of someone having the time to do it, including integration with the add-ons repository.

[nvaccessAuto]

Comment 7 by nvdakor on 2015-04-26 05:54 Hi, After some investigation, it appears it might be doable. The biggest challenge is the mechanism to integrate with the add-ons repository. Recording the URL and then downloading and instaling the add-on is easy (we can borrow ideas from update check's UpdateDownloader class); the issue is how to differentiate between current and the newer add-on (hashing may work).

The big picture could be the following:

1. Add an update button in the add-ons manager if the add-on manifest specifies an update URL. This could be either the repurposed URL field from the current manifest format, or it could be a new field just for this purpose.
2. When the update button is clicked, a routine similar to update check routine from NVDA core would run, attempting to compare hashes and version and so on, which will result in the update UI similar to that of NVDA core.
3. Once the update is downloaded, the add-on installation UI should come up, asking users if they wish to install the new add-on.

Issues to be resolved:

• How can we calculate the first hash for our add-ons?
• How should the web server which hosts add-ons website communicate with NvDA core as to comparing hashes, add-on version and so on?

I think anyone can implement the client side, and Mesar knows more about the server side unless if Jamie has access to that server. We also need to hear from add-on authors so we can prepare our add-ons to take advantage of this idea in the future. Thanks.

[nvaccessAuto]

Comment 8 by jteh (in reply to comment 7) on 2015-04-27 03:50 Replying to nvdakor:

Recording the URL and then downloading and instaling the add-on is easy (we can borrow ideas from update check's UpdateDownloader class);

Ideally, that code should be refactored so that it can be reused rather than duplicating it. I started work on this a while ago (#3504), but never got around to finishing it.

the issue is how to differentiate between current and the newer add-on (hashing may work).

Keep it simple. Just compare the old version with the new version. If it's different, consider it an update. This is all we do for NVDA updates. That doesn't account for someone running a versio that is newer than is available on the site, but if that happens, the user clearly is a developer and/or is working with one.

1. Add an update button in the add-ons manager

We should also consider automatic updates.

if the add-on manifest specifies an update URL.

I'm leaning towards restricting this functionality to the official add-ons repository, which means we don't need a full update URL, just some key indicating that this can do updates.

• How can we calculate the first hash for our add-ons?

See above. We don't need hashes for version identification. We do need hashes for verifying file integrity, but those can be generated automatically.

Also, I don't think this needs to magically start working for existing add-ons. I think it's acceptable to require that users download a new version of the add-on initially to have it start updating.

• How should the web server which hosts add-ons website communicate with NvDA core as to comparing hashes, add-on version and so on?

We could do something similar to the current NVDA update check server script. The bigger issue is actually having a database on the server of add-ons and versions. Currently, as I understand it, version information is only listed in the Markdown for the website, which is not something we can reliably use.

I think anyone can implement the client side, and Mesar knows more about the server side unless if Jamie has access to that server.

The entire translation and add-ons system is now all running on the NV Access server. Mesar is pretty busy with other things these days and I haven't seen much from him lately, so I'm now handling everything related to this (unless Mesar wants to step in). I have a pretty good understanding of some parts of the system, though am still learning my way around others.

[nvaccessAuto]

Comment 9 by nvdakor (in reply to comment 8) on 2015-04-27 03:59 Replying to jteh:

Replying to nvdakor:

Recording the URL and then downloading and instaling the add-on is easy (we can borrow ideas from update check's UpdateDownloader class);

Ideally, that code should be refactored so that it can be reused rather than duplicating it. I started work on this a while ago (#3504), but never got around to finishing it.

If you've started on this, then I think we should wait until #3504 is in place before returning to this ticket. Besides, update downloader and installer GUI has issues - for instance, the GUI for update downloader doesn't close automatically once an update has been downloaded and multiple update progress GUI may appear after a failed update is attempted.

1. Add an update button in the add-ons manager

We should also consider automatic updates.

if the add-on manifest specifies an update URL.

I'm leaning towards restricting this functionality to the official add-ons repository, which means we don't need a full update URL, just some key indicating that this can do updates.

Understood.

Also, I don't think this needs to magically start working for existing add-ons. I think it's acceptable to require that users download a new version of the add-on initially to have it start updating.

Sure. I'd say we the authors need at least three months time to adjust to the new routines once this ticket has been implemented; whatever major version of the add-on we were working on, that version or the version after that can implement needed changes, similar to what happened last fall when we started implementing add-on help functionality. Thanks.

[nvaccessAuto]

Comment 10 by nvdakor on 2015-10-02 01:40 Hi, Coming back to this ticket... Looking at urllib and NvDA Core's update routines ghave me an idea as to how to implement client side, but for version 1, it'll require user intervention. The proposal is as follows:

1. Add-ons should specify the download URL (perhaps a new key). This can be done easily, as many add-ons come with readme files written in Markdown that specifies URL's for stable and development versions.
2. When update button is clicked, NVDA will gather the add-on manifest for the selected add-on, which will return add-on version, URL and so on. Perhaps a call to locate the add-on installer size should be specified for dev versions.
3. NVDA will open the URL via urllib.urlopen, parse the URL and look at content length header. Thankfully, because of the add-on file naming convention in use, it is easy to parse the address looking for the version information (a couple calls to strip function).
4. If the version on the server is newer than the installed add-on, assume that a newer version is available and present the update dialog (borrow NVDA Core's update presentation dialog, rewording parts of it to refer to add-ons).
5. If a development version is being updated, check the content length against the size of the add-on installer for the currently installed add-on (initially the client side is 0), and if they are different, assume that a new version is available and act accordingly.
6. For steps 4 or 5, if an update is downloaded, save the content length for future update lookup.
7. Until #3504 is implemented, NVDA will call os.startfile. I'd be happy to write a proof of concept add-on that demonstrates this algorithm. Thanks.

[nvaccessAuto]

Comment 11 by jteh (in reply to comment 10) on 2015-10-02 08:29 Replying to nvdakor:

1. Add-ons should specify the download URL (perhaps a new key).

I'm still thinking we should restrict this to the official add-on repository. Also, there are actually two URLs required in your proposed system: the URL for the manifest and the URL for the add-on itself.

1. When update button is clicked, NVDA will gather the add-on manifest for the selected add-on, which will return add-on version, URL and so on.

As noted in comment:8, I think this is better done with a server script similar to the current update check server. This centralises things and allows for tracking of statistics (though that's of course not required for the first round).

1. If a development version is being updated, check the content length against the size of the add-on installer for the currently installed add-on (initially the client side is 0), and if they are different, assume that a new version is available and act accordingly.

This is going to be fragile. Honestly, I think dev versions should just increment the version number (like NVDA snapshots do) if users really are supposed to update.

Thanks.

[josephsl]

Hi all,

@derekriemer and I had a talk about how to implement the server side (client side can be done easily). @nvdaes said on the add-ons mailing list that a file that lists add-on keys and versions would be sufficient, but Derek believes a database would be much better (I agree). The questions are what (database), when (if someone has time), and how (procedure).

CC @jcsteh

[derekriemer]

Hi, I can open another ticket for this, I'd like an opinion from @jcsteh on this though. I think when we do this, signing all community add-ons, and only allowing installation of community add-ons until a box is unchecked authorizing that unreviewed add-ons may be installed. This has these advantages.

1. Add-ons can check whether the new bundle is properly signed.
2. When NVDA Boots, it checks the signature of all add-ons if the allow untrusted add-ons option is unchecked. It refuses to load any untrusted add-ons.
3. When a user tries to install an add-on, if the add-on is not signed, it tells them this is an untrusted andd-on, and prompts them to change their settings if they really want untrusted add-ons.
4. When updates occur, the add-on bundle must be signed before it will install.

[derekriemer]

Also, a post request for this would be desired, with all the add-ons being specified. I.E. { "rf": { "version" : "2.2.2", "beta" : false, "hash" : "987987987987987987987987" }, "ocr" : { "version" : "2.1", "beta" : false, "hash" : "d53929098d550098409834409824..." }, ... } with json being returned of the form { "rf" : { "version" : 2.5.0", "beta" : false, ... } }

[rkingett]

Could all the add on's be hosted on Git Hub and then someone uses the Git Hub server to keep the costs down? & would that be an easier way to have NVDA check for updates?

[LeonarddeR]

This seemed to be quite an interesting ticket to read. Here are my thoughts.

1. Although I can see why @jcsteh proposes add-ons can only be updated from a central server, this might cause problems for paid add-ons (such as speech synths) which are not in the community repository since they are not or not entirely open source. Even for non-open source add-ons, I think there should be a pathway for automatic updates. Two alternatives: A. Only allow third party unregistered add-ons to be updated from a https source with verified SSL certificate B. Cumulatively, Allow add-ons from other sources and their corresponding url's to be registered on the centralised add-on system.

[jcsteh]

I agree we want paid add-ons to get automatic updates. I imagined we would have them registered with our central repository, even though you probably wouldn't be able to actually purchase them from there.

[feerrenrut]

P3. This seems like it would take a large amount of time to implement, and is not currently stopping primary use cases. It would however be very convenient.

@jcsteh Perhaps the priority should be higher if this is considered of strategic importance to NVDA?

[jcsteh]

I think this is something we really do want, but there is just so much other higher priority work that I can't justify making it p2 right now.

[rkingett]

A lot of people have no idea where to get add on updates, though, or even that an add on has updated, so this would seriously be more than just a convenience

On 11/13/2016 11:29 PM, Reef Turner wrote:

P3. This seems like it would take a large amount of time to implement, and is not currently stopping primary use cases. It would however be very convenient.

@jcsteh https://github.com/jcsteh Perhaps the priority should be higher if this is considered of strategic importance to NVDA?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-260251651, or mute the thread https://github.com/notifications/unsubscribe-auth/AMj7zJ0QpOnkrL1fZnuKML9ZGP0oEp5mks5q9_HAgaJpZM4JXkpI.

[josephsl]

Hi,

After doing some more research and talking with @DerekRiemer, it appears the best possible server side implementation would be that of a table that includes info such as add-on name, description, version, download link and hash and so on, with another table reserved strictly for add-on updates. When the client looks up add-on updates, the client should specify add-on update channel, then the server should return update info such as version, download link and hash.

For example, suppose we use the URL of the form: https://addons.nvaccess.org/updateCheck?name=addon_channel

For instance, Windows 10 App Essentials dev version could say: https://addons.nvaccess.org/updateCheck?name=wintenApps-dev

The server should return nothing if the version is up to date or a response similar to how NVDA Core checks for new versions (version, download link, hash).

For add-ons, a new manifest key named "addon_updateChannel" or something similar could be added, with the default value being "None" (no info). However, before the add-on updates database says that the specified add-on does not exist, the server would assume that one wants to update to the latest stable branch. Ideally, a new add-on that does include update name should be used.

Additional comments are appreciated. Thanks.

[derekriemer]

Note from @Jcsteh:

Don't put description in that table, it's problematic for l10n. We'll need another table for that.

We need to make the constraint unique across name-channel pairs.

On 1/15/2017 7:19 PM, Joseph Lee wrote:

Hi,

After doing some more research and talking with @DerekRiemer https://github.com/DerekRiemer, it appears the best possible server side implementation would be that of a table that includes info such as add-on name, description, version, download link and hash and so on, with another table reserved strictly for add-on updates. When the client looks up add-on updates, the client should specify add-on update channel, then the server should return update info such as version, download link and hash.

For example, suppose we use the URL of the form: https://addons.nvaccess.org/updateCheck?name=addon_channel

For instance, Windows 10 App Essentials dev version could say: https://addons.nvaccess.org/updateCheck?name=wintenApps-dev

The server should return nothing if the version is up to date or a response similar to how NVDA Core checks for new versions (version, download link, hash).

For add-ons, a new manifest key named "addon_updateChannel" or something similar could be added, with the default value being "None" (no info). However, before the add-on updates database says that the specified add-on does not exist, the server would assume that one wants to update to the latest stable branch. Ideally, a new add-on that does include update name should be used.

Additional comments are appreciated. Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-272759250, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGiveFSOhB9tUP-F64Ygiq614BfXBuwks5rStPOgaJpZM4JXkpI.

--

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected] Phone: (303) 906-2194

[jcsteh]

Two tables are being suggested here (one for the version info and one for updates), but I think you only need one which is used for both. The unique constraint ensures there's only ever one "current" version for each channel. Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default, etc.

[derekriemer]

Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default,

This is problematic in two ways.

Assume that there are two versions of an expensive app A.

a version 3.0 and 4.0.

The author has and maintains a branch for 3.0 Long term support, only maintenance, but provides regular updates for version 4.0.

Now assume a new version of 4.0, 4.1 is released, and 5.0 is released. The author would like to release the stable and normal beta, with tag dev, and a 5.0-dev at the same time. Maybe in this case, we just don't use the update system? Thoughts?

On 1/15/2017 10:11 PM, James Teh wrote:

Two tables are being suggested here (one for the version info and one for updates), but I think you only need one which is used for both. The unique constraint ensures there's only ever one "current" version for each channel. Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default, etc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-272775410, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivXBie0QY5HI3iDs6_Gt2PAJ5IoGAks5rSvvkgaJpZM4JXkpI.

--

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected] Phone: (303) 906-2194

[LeonarddeR]

I'd say this would make the update system needlessly complicated. For NVDA, we do not have lts releases either, so why do we even want this for add-ons?

N.B. Sent on behalf of @BabbageCom

Op 16 jan. 2017 om 06:33 heeft derekriemer [email protected] het volgende geschreven:

Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default,

This is problematic in two ways.

Assume that there are two versions of an expensive app A.

a version 3.0 and 4.0.

The author has and maintains a branch for 3.0 Long term support, only maintenance, but provides regular updates for version 4.0.

Now assume a new version of 4.0, 4.1 is released, and 5.0 is released. The author would like to release the stable and normal beta, with tag dev, and a 5.0-dev at the same time. Maybe in this case, we just don't use the update system? Thoughts?

On 1/15/2017 10:11 PM, James Teh wrote:

Two tables are being suggested here (one for the version info and one for updates), but I think you only need one which is used for both. The unique constraint ensures there's only ever one "current" version for each channel. Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default, etc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-272775410, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivXBie0QY5HI3iDs6_Gt2PAJ5IoGAks5rSvvkgaJpZM4JXkpI.

--

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected] Phone: (303) 906-2194

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jcsteh]

Agree with Leonard on this. Three things worth noting:

1. Something that complicated is probably going to cause problems for the website anyway, since there's no common terminology/layout.
2. Deciding on a set of common names doesn't mean we can't add to that set later. If LTS really does become a really common thing, we can add it when it's needed. I'm not suggesting a data schema that enforces a set of names; I'm suggesting this be enforced by the UI for now.
3. The system could actually support channels other than the default set, but the add-on author has to provide the initia link to their testing users in thsi case. That isn't incompatible with anything else in the proposal so far.

Jamie

On Mon, Jan 16, 2017 at 3:37 PM, Leonard de Ruijter < [email protected]> wrote:

I'd say this would make the update system needlessly complicated. For NVDA, we do not have lts releases either, so why do we even want this for add-ons?

N.B. Sent on behalf of @BabbageCom

Op 16 jan. 2017 om 06:33 heeft derekriemer [email protected] het volgende geschreven:

Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default,

This is problematic in two ways.

Assume that there are two versions of an expensive app A.

a version 3.0 and 4.0.

The author has and maintains a branch for 3.0 Long term support, only maintenance, but provides regular updates for version 4.0.

Now assume a new version of 4.0, 4.1 is released, and 5.0 is released. The author would like to release the stable and normal beta, with tag dev, and a 5.0-dev at the same time. Maybe in this case, we just don't use the update system? Thoughts?

On 1/15/2017 10:11 PM, James Teh wrote:

Two tables are being suggested here (one for the version info and one for updates), but I think you only need one which is used for both. The unique constraint ensures there's only ever one "current" version for each channel. Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default, etc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-272775410,

or mute the thread <https://github.com/notifications/unsubscribe- auth/AFGivXBie0QY5HI3iDs6_Gt2PAJ5IoGAks5rSvvkgaJpZM4JXkpI>.

--

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected] Phone: (303) 906-2194

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-272777894, or mute the thread https://github.com/notifications/unsubscribe-auth/AD-TS2ESm7H-FPNvcU4cdb-oiSE1SrVfks5rSwIvgaJpZM4JXkpI .

[derekriemer]

Can you explain 3?

On 1/15/2017 11:06 PM, James Teh wrote:

Agree with Leonard on this. Three things worth noting:

1. Something that complicated is probably going to cause problems for the website anyway, since there's no common terminology/layout.
2. Deciding on a set of common names doesn't mean we can't add to that set later. If LTS really does become a really common thing, we can add it when it's needed. I'm not suggesting a data schema that enforces a set of names; I'm suggesting this be enforced by the UI for now.
3. The system could actually support channels other than the default set, but the add-on author has to provide the initia link to their testing users in thsi case. That isn't incompatible with anything else in the proposal so far.

Jamie

On Mon, Jan 16, 2017 at 3:37 PM, Leonard de Ruijter < [email protected]> wrote:

I'd say this would make the update system needlessly complicated. For NVDA, we do not have lts releases either, so why do we even want this for add-ons?

N.B. Sent on behalf of @BabbageCom

Op 16 jan. 2017 om 06:33 heeft derekriemer [email protected] het volgende geschreven:

Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default,

This is problematic in two ways.

Assume that there are two versions of an expensive app A.

a version 3.0 and 4.0.

The author has and maintains a branch for 3.0 Long term support, only maintenance, but provides regular updates for version 4.0.

Now assume a new version of 4.0, 4.1 is released, and 5.0 is released. The author would like to release the stable and normal beta, with tag dev, and a 5.0-dev at the same time. Maybe in this case, we just don't use the update system? Thoughts?

On 1/15/2017 10:11 PM, James Teh wrote:

Two tables are being suggested here (one for the version info and one for updates), but I think you only need one which is used for both. The unique constraint ensures there's only ever one "current" version for each channel. Even though the channel names can be arbitrary, I suggest the site restrict it to well known names so that we know which to use by default, etc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub

https://github.com/nvaccess/nvda/issues/3208#issuecomment-272775410,

or mute the thread <https://github.com/notifications/unsubscribe- auth/AFGivXBie0QY5HI3iDs6_Gt2PAJ5IoGAks5rSvvkgaJpZM4JXkpI>.

--

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected] Phone: (303) 906-2194

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub

https://github.com/nvaccess/nvda/issues/3208#issuecomment-272777894, or mute

the thread

https://github.com/notifications/unsubscribe-auth/AD-TS2ESm7H-FPNvcU4cdb-oiSE1SrVfks5rSwIvgaJpZM4JXkpI

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-272780861, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivX1gsxs86PyrDGusZsxUwtCKJA-Oks5rSwjcgaJpZM4JXkpI.

--

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected] Phone: (303) 906-2194

[jcsteh]

Well, the foo add-on could have a stable channel, a beta channel and a dev channel. Those are the default set, but it could also have a bar channel. We probably wouldn't expose that bar channel link via the website, but the initial download link could be distributed via other means. This would allow for "snapshot branches". I don't think we should necessarily implement this for any UI in the first phase, but the point is that the schema does allow it.

[derekriemer]

Ah, gotcha.

On 1/15/2017 11:19 PM, James Teh wrote:

Well, the foo add-on could have a stable channel, a beta channel and a dev channel. Those are the default set, but it could also have a bar channel. We probably wouldn't expose that bar channel link via the website, but the initial download link could be distributed via other means. This would allow for "snapshot branches". I don't think we should necessarily implement this for any UI in the first phase, but the point is that the schema does allow it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-272782383, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivU8O8yG70mLMLik7T45N-pdFsTIQks5rSwwEgaJpZM4JXkpI.

--

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected] Phone: (303) 906-2194

[rkingett]

speaking as a user, I always look for the latest of whatever add on. I do not use older add ons. I think a lot of novice and intermediate users would want everything in one table so they always get the latest add on updates.

[derekriemer]

The table is internal to the site. The user won't know its happening.

On 1/16/2017 3:02 AM, rkingett wrote:

speaking as a user, I always look for the latest of whatever add on. I do not use older add ons. I think a lot of novice and intermediate users would want everything in one table so they always get the latest add on updates.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/3208#issuecomment-272819469, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivblO-ltDT-FXixuXcMzvvY8M9VDGks5rS0BRgaJpZM4JXkpI.

--

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected] Phone: (303) 906-2194

[josephsl]

Hi,

A progress report: some progress has been made in abstracting away the update downloader, a clearer picture on client, server and UI.

1. Abstracting the downloader: the latest development snapshots of Windows 10 App Essentials and StationPlaylist Studio add-ons include a subclass of updateCheck.UpdateDownloader tailored for these add-ons. No need to override GUI exec routines (the only thing to be modified are methods that deal with tempfile destination, GUI strings and download URL). As for ShellExecute, just run the .nvda-addon file (no arguments needed). The subclass does allow installed copies of NVDA to download add-on bundles (I've intentionally limited this to installed copies) and it works on both HTTP and HTTPS.
2. Client GUI: I'm working on this at the moment (branch i3208-updateAddonsClient) in my fork. This branch will add a new button in add-ons manager called "Check for Add-on Update" (pneumonic: U). Once clicked, it'll use similar routine as in NVDA Core update (a background thread to communicate with the server via urllib and parse the results) to look up add-on update info from a website (add-ons website). To guarantee support for different fetch and result parsing mechanisms, a function should be used to let the add-ons manager know if a new add-on version is available (similar to how NVDA Core uses a dictionary to let users know about this). Once the user chooses to update, the add-on will be downloaded and installed if one is using an installed copy (which naturally raises the question about portable versions). In case of installed copy, once the new add-on bundle is downloaded, go through install phase (portable version will be different).
3. Server: Database is the best solution with at least three tables: add-on versions, download links and hashes, and list of add-ons that might be questionable (illegal synthesizers, for instance). The basic syntax (in SQL/PostGreSQL) is listed below. In terms of server mechanics, questionable add-ons table is consulted, then consult versions if the add-on is safe. Once the version does not match, the server should send update file/hash info as a JSON or a similar format back to clients. As @DerekRiemer noted, a post method would be best in case multiple add-ons will be looked up.

As for server tables:

Add-on version table: CREATE TABLE table1( name TEXT PRIMARY Key NOT NULL, channel TEXT PRIMARY Key, version TEXT NOT NULL )

Add-on info table: CREATE TABLE table2( name TEXT PRIMARY KEY NOT NULL, channel TEXT PRIMARY KEY, version TEXT PRIMARY KEY NOT NULL, description TEXT NOT NULL, author TEXT NOT NULL, filename TEXT NOT NULL, filehash TEXT NOT NULL )

Questionable add-ons: CREATE TABLE table3( name TEXT PRIMARY KEY NOT NULL, version TEXT )

Notes:

• Table names are arbitrary (it's up to server-side implementers to choose the table names, but to the outside world, what matters the most is the URL encoding and version info that'll be returned).
• If "channel" is not present, assume stable channel.
• Filename refers to the URL from where the update can be downloaded from.
• Filehash refers to hash for the add-on bundle.
• Version is a string.
• The absolute minimum info that should be encoded as URL's are add-on name and version (channel is optional unless a specific channel is requested).

As for my SQL syntax, this is a mixture of real life and idealized syntax, and I used PostGreSQL syntax.

Comments on this updated design is appreciated. Thanks.