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

Luke Davis

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.