Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing


I should have said, "I felt" when talking about the proposal.

-----Original Message-----
From: <> On Behalf Of Joseph Lee via Groups.Io
Sent: Friday, November 22, 2019 9:06 PM
Subject: Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

Part of the reason why it is a bit difficult to test the pull request as it stands and the complexity of Add-on Updater at the moment is due to add-on name/ID to shorthand lookup. Whenever an add-on is added to community add-ons website, a shorthand is created, which is then added to Add-on Updater (I call this "registration"). This ad-on name/shorthand map is then updated via Add-on Updater whenever the new version of Add-on Updater is released. The proposal here is to store the add-on name alongside shorthands on the server side, rather than letting Add-on Updater carry this map.
In an ideal situation what James is proposing should take place: just create the add-ons metadata database rather than duplicating entries. But I feel that in order to at least test the viability of this approach, some kind of a testbed should be created somewhere.
As for numeric ID's, this will work if the add-on updater client (that's the portion I'm working on) sends a list of installed add-ons alongside NVDA version and Windows version one is using to the add-ons server. At the high level, all the server needs to do is return a map (encoded via JSON at least) that records names of add-ons with updates, along with metadata such as version, URL, and hash for each entry. In short, what we really need is a group of people that will work on the server and transport infrastructure, along with training add-on authors as to how to update their add-on metadata via a user interface - that is, transforming our current add-on files Git repo push/pull mechanism to database transactions.
I know I'm ranting and might be showing my frustration and anger at this point (angry at myself), and after thinking about the below post, I begin to wonder if I am indeed losing touch with reality... Luke and James are right.
P.S. Usually I'm not like this - being in control of a situation and not displaying breakdowns like this. Dear NVDA community, please HELP ME!!!

-----Original Message-----
From: <> On Behalf Of Luke Davis
Sent: Friday, November 22, 2019 3:27 PM
Subject: Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

On Fri, 22 Nov 2019, Joseph Lee wrote:

Currently add-on files database, which hosts links for add-on
downloads, uses shorthands to store add-on link information. Iā€™m
thinking about adding add-on name/ID entries to this database, both to
simplify Add-on Updater add-on and to serve as a proof of concept for
a future add-ons metadata database, which will host metadata such as add-on version, description, changelog paragraph for a new version, compatibility range flags and other useful information. This metadata database, which is being designed by several community members, will also serve as a backbone for future add-on updating functionality in NVDA screen reader.
I have two points.

1. If any part of that was referencing the work that Derek and I are doing, I will note that by its nature, the PostGreSQL database used will include guaranteed unique numeric IDs for each add-on.

2. That aside, I completely agree with James Scholes, in not really understanding what problem adding a third identifier will solve.

A. We have the actual single-word add-on name that everything uses to one degree or another.
B. We have the shorthand form that the add-on site wiki imposes on us because of localization length limits.
C. Now you want to add a third unique alpha-numeric identifier for reasons that don't seem clear when we already have two unique identifiers.
D. Whether the work Derek and I are doing is ultimately accepted, or whether someone else does something that is, surely any database will have a unique numeric identifier of some kind associated with each add-on. I have not seen the current database, but I'm kind of surprised it doesn't have one already.

So, my question is: why not use A, or B, or D in the work you are doing? Why add C?

More than just practicality, I note the below:

* For now if this proposal is adopted, only Add-on Updater will use the new keys. In the end, both Add-on Updater and the eventual add-on update feature
in NVDA will consult the new add-on metadata database.
I'm not clear on whether that means it will use this new identifier, in which case we're all stuck with the new identifiers and having to maintain them for the long term, or if it means that you will throw out the new identifiers and use the new metadatabase you are talking about.
In the first case, then I strongly oppose adding a new set of identifiers now.
In the latter case then I reiterate my question above: what's the point? Use one of the existing unique identifiers, and eliminate half the work involved since it's all going to be ripped out in some months anyway.

The biggest advantage is simplified Add-on Updater and add-on updating
functionality in NVDA screen reader ā€“ one can just check add-on name/ID and figure out if an update is available. The drawback is duplicate entries and prone to typos, along with translation concerns.
While that is a significant drawback, I would like to understand what stands in the way of doing the first part now? Why can't you check name and database number, or name and short identifier, or whatever arrangement is needed?

Are you suggesting that the existing identifiers are not unique?

* The new add-on name/ID keys will not be visible to the public via community add-ons website ā€“ shorthands will still be used. This should minimize
translation issues.
Numeric IDs would minimize them more.


Join to automatically receive all group messages.