On Fri, 22 Nov 2019, Joseph Lee wrote:
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.As I understand what you are saying, you would alter the existing addons names table, and add a nickname column.
Thus making your look-up process easier.
That seems perfectly reasonable if it is considered a temporary measure to help with update deployment.
My objection is to two things:
1. Considering that in any way to be other than a temporary measure. I would hate to see the nicknames system become part of core, because the wiki software which demands them will probably go away as something new comes online. If it is just intended to help with the current add-on updater add-on, I think it would be fine.
2. Your original proposal suggested adding a new nickname, in addition to the wiki-based one that is used in URLs. I think that adds a layer of complexity and maintenance that is just unnecessary, which I think you have now realized.
So, what I'm saying is:
If your proposal is to take the existing nicknames that the wiki based system uses, and add those to a new column in the names table to provide a one-to-one mapping for use exclusively by add-on updater, I would not complain about that.
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.Then make a new table in the existing database. If the existing add-on names are a key, use those as the unique foreign key for your new table, put the current wiki-derived nicknames in there along side the add-on names, and point add-on updater to it to get its information.
That way you have zero impact on the current arrangement if you need to suddenly revert thereto. I.E. something like this (unchecked):
CREATE TABLE addon_handles (
id serial unique,
name varchar(255) character set UTF8 not null default '' primary key
comment "Long to allow enough length for multibyte characters"
REFERENCES main_addons_table(addon_name_column) on delete cascade,
handle varchar(50) not null
comment "Nickname used for URLs and NVDA internals" -- May not need to be UTF8
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,Which is what Derek and I have been doing, all be it both getting frequently distracted by other things.
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!!!It's a forest and trees problem. We can get so focused on a particular way of doing a thing, that alternatives do not even occur to us. If it didn't also happen to you, I would fear for your humanity.