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-onI 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 featureI'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 figureWhile 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 minimizeNumeric IDs would minimize them more.