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

Noelia Ruiz

I am reading previous messages in this thread and mine is quite vague. WHAT I mean is that I like the idea of creating a database so that in the future NVDA can differenciate between add-ons considered secure, just it. I agree in doing proof of concept testing if this would bring some benefit. For me addonUpdater is useful to update some addons in a comfortable way without searching on the website. But if it needs to be stored by NV Access in its server, may be good to wait for his opinion before testing. I mean that they may know how to do this in a precise way, probably without using addonFiles, and in this case previous modifications for testing may not be useful. Maybe they can do this very quickly, of course consulting with the community, and in this case it could be better to wait until they are available to work on this before changing things.

Enviado desde mi iPhone

El 23 nov 2019, a las 0:26, Luke Davis <luke@...> escribió:

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.