New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to automatically update add-ons #3208
Comments
Comment 1 by blindbhavya on 2014-09-07 08:27 |
Comment 3 by bhavyashah on 2015-01-01 07:44 |
Comment 5 by fastfinge on 2015-02-19 16:17 |
Comment 6 by jteh on 2015-02-20 01:17 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. |
Comment 7 by nvdakor on 2015-04-26 05:54 The big picture could be the following:
Issues to be resolved:
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. |
Comment 8 by jteh (in reply to comment 7) on 2015-04-27 03:50
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.
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.
We should also consider automatic updates.
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.
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.
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.
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. |
Comment 9 by nvdakor (in reply to comment 8) on 2015-04-27 03:59
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.
Understood.
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. |
Comment 10 by nvdakor on 2015-10-02 01:40
|
Comment 11 by jteh (in reply to comment 10) on 2015-10-02 08:29
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.
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).
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. |
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 |
Hi,
|
Also, a post request for this would be desired, with all the add-ons being specified. I.E. |
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? |
This seemed to be quite an interesting ticket to read. Here are my thoughts.
|
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. |
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? |
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.
|
A lot of people have no idea where to get add on updates, though, or On 11/13/2016 11:29 PM, Reef Turner wrote:
|
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: 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. |
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
<#3208 (comment)>,
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 derek.riemer@colorado.edu <mailto:derek.riemer@colorado.edu>
Phone: (303) 906-2194
|
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.
|
…pdated when update dialog is shown. Re nvaccess#3208. Add checkboxes (list control) to add-on updates dialog so users can select which add-ons should be updated. By default, checkboxes are not checked, but one can check add-ons one wishes to update. Also, whenever checkboxes are checked, check if update button should be enabled or not based on if at least one add-on is checked for update installation (via Python's any() function).
…ing is not supported. Re nvaccess#3208.
…p if told to do so via a callback. Re nvaccess#3208. Possibly due to threading issue: GUI works correctly if queued from the main thread. One way to do this is via a callback that is claled by wx.CallAfter. Thus use an internal callback when NVDA needs to display add-on update results dialog at startup.
…king turned off. Re nvaccess#3208. Add a new set in add-on state that'll record add-ons for which update checking should not be done. With this active, add-on update check function will skip add-ons listed in that set.
…various add-ons. Re nvaccess#3208. A new button in Add-ons Manager will open a checkable list where users can turn off add-on update checks. To turn update checking off, one would check the box for the add-on in question. Once OK button is clicked, a record of checked add-ons will be saved to add-on state and will be written to disk just to make sure the record is saved in the event of disasters.
…ing in surroudning paragraphs. Re nvaccess#3208.
Hi, Update for November 2018: I'm slowly incorporating lessons learned from Add-on Updater add-on into this pull request. at the moment almost all features from that add-on are present except for choosing update channel. most notably, two outstanding issues/requests were done:
Thanks. |
…ded NVDA 'update' is not required. Re nvaccess#3208. Add a keyword in UpdateDownader class that will ask the downloader to retrieve file version information. If set to yes, file version info will be retrieved, otherwise this step will be skipped. The only time the new keyword will be set to False is if updating add-ons, as add-on bundles do not come with file version metadata, although this might change in the future.
…vaccess#3208. Add-ons Manger's instlal add-on function can now update add-ons, performing different steps along the way. Also, remote add-on installer will be used to perform add-on updates if the newly added fresh instlal argument is false. Specificlaly: * Moved add-on update steps (at least the user interface) from add-on update downloader to Add-ons Manager class, thus unifying the routines. * A new keyword named 'freshInstall' will be used to tell Add-ons Manager if installation wil involve updating (false) or a complete instlal (true). * Depending on value of fresh install keyword, different messages will be presented when 'instlaling' add-ons while updating. * Remote add-on installer has gained 'freshInstall' keyword for use in add-on update only (this keyword may become private if necessary). * During add-on updates, install confirmation message won't be shown. The only interaction will be when the new add-on release is not compatible with current version of NVDA (see issue 6275 for more information).
… Windows Store application. Re nvaccess#3208.
…branch. Re nvaccess#3208. Specifically: * Instead of calling remote add-on instlal handler, the new install add-on function will be called. * The add-oin install logic is now part of the new installAddon function that has been moved to outside of add-on GUI class. * Due to introduction of restart prompt function, add-on update generator will call the new function instead of going through add-ons manager/close event.
…r enforced. Re nvaccess#3208. As part of revised add-on compatibility approach, file version check is no longer performed by update downloader, thus remove this flag from update downloader and subclasses.
…add-on handler. Re nvaccess#3208.
…t least one add-on is installed. Re nvaccess#3208. Enable add-on update check settings if add-ons are installed (perviously it was showing all the time due to a logic error regarding add-on list refresh).
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
The text was updated successfully, but these errors were encountered: