Topics

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

 

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph

 

Joseph,


For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.


Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph

 

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on does have a field for it as part of the downloader class.

As for database schema, we have:

  • Add-on ID/name (string)
  • Friendly name (string
  • Current version (string)
  • New version (string)
  • Minimum NVDA version (string)
  • Last tested NVDA version (string)
  • Hash (SHA256 minimum)
  • Changelog (text)
  • Download URL (URL)
  • Author contact information (string and email address)

 

 

To answer James’s question: yes, designing the new database should be done. But I think there should be a way to prototype it, and using current infrastructure gives us an avenue to do so – in the end, Add-on Updater is really a testbed for the pull request I’m working on, so that add-on will have everything (or almost everything) the pull request will have.

Cheers,

Joseph

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Friday, November 22, 2019 9:56 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Joseph,

 

For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.

 

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph

 

Dear Joseph,


I'm not sure why we need a current version and new version string.

I would also say that it would help to identify all channels that are available for an add-on with the same add-on name, i.e. don't distinguish between wintenApps and wintenApps-dev at the identifier levels, but allow adding multiple channels/versions per add-on.


Regards,

Leonard

Op 22-11-2019 om 19:05 schreef Joseph Lee:

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on does have a field for it as part of the downloader class.

As for database schema, we have:

  • Add-on ID/name (string)
  • Friendly name (string
  • Current version (string)
  • New version (string)
  • Minimum NVDA version (string)
  • Last tested NVDA version (string)
  • Hash (SHA256 minimum)
  • Changelog (text)
  • Download URL (URL)
  • Author contact information (string and email address)

 

 

To answer James’s question: yes, designing the new database should be done. But I think there should be a way to prototype it, and using current infrastructure gives us an avenue to do so – in the end, Add-on Updater is really a testbed for the pull request I’m working on, so that add-on will have everything (or almost everything) the pull request will have.

Cheers,

Joseph

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Friday, November 22, 2019 9:56 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Joseph,

 

For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.

 

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph

 

Hi,

Ah yes, I forgot to mention that channel is one of the columns (string). Sorry about that.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Friday, November 22, 2019 10:34 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Dear Joseph,

 

I'm not sure why we need a current version and new version string.

I would also say that it would help to identify all channels that are available for an add-on with the same add-on name, i.e. don't distinguish between wintenApps and wintenApps-dev at the identifier levels, but allow adding multiple channels/versions per add-on.

 

Regards,

Leonard

Op 22-11-2019 om 19:05 schreef Joseph Lee:

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on does have a field for it as part of the downloader class.

As for database schema, we have:

  • Add-on ID/name (string)
  • Friendly name (string
  • Current version (string)
  • New version (string)
  • Minimum NVDA version (string)
  • Last tested NVDA version (string)
  • Hash (SHA256 minimum)
  • Changelog (text)
  • Download URL (URL)
  • Author contact information (string and email address)

 

 

To answer James’s question: yes, designing the new database should be done. But I think there should be a way to prototype it, and using current infrastructure gives us an avenue to do so – in the end, Add-on Updater is really a testbed for the pull request I’m working on, so that add-on will have everything (or almost everything) the pull request will have.

Cheers,

Joseph

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Friday, November 22, 2019 9:56 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Joseph,

 

For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.

 

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph

Noelia Ruiz
 

Hi, though I don't have a precise way to implement this, I agree with
the general idea. Also, we have to address the fact that there are
add-ons considered secure though they aren't stored in addonFiles
repo, for example syntesizers, announced by NV Access or by the
community as secure add-ons. In the other hand, many of us have seen
reops or websites providing add-ons stored in the community, maybe
stored in their own servers or providing a link to addonFiles.
Cheers

2019-11-22 19:47 GMT+01:00, Joseph Lee <@joslee>:

Hi,

Ah yes, I forgot to mention that channel is one of the columns (string).
Sorry about that.

Cheers,

Joseph



From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de
Ruijter
Sent: Friday, November 22, 2019 10:34 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files
database to include add-on name/ID for easier comparison and for
future-proofing



Dear Joseph,



I'm not sure why we need a current version and new version string.

I would also say that it would help to identify all channels that are
available for an add-on with the same add-on name, i.e. don't distinguish
between wintenApps and wintenApps-dev at the identifier levels, but allow
adding multiple channels/versions per add-on.



Regards,

Leonard

Op 22-11-2019 om 19:05 schreef Joseph Lee:

Hi,

Ah yes, hash: that's the reason why the pull request I'm working on does
have a field for it as part of the downloader class.

As for database schema, we have:

* Add-on ID/name (string)
* Friendly name (string
* Current version (string)
* New version (string)
* Minimum NVDA version (string)
* Last tested NVDA version (string)
* Hash (SHA256 minimum)
* Changelog (text)
* Download URL (URL)
* Author contact information (string and email address)





To answer James's question: yes, designing the new database should be done.
But I think there should be a way to prototype it, and using current
infrastructure gives us an avenue to do so - in the end, Add-on Updater is
really a testbed for the pull request I'm working on, so that add-on will
have everything (or almost everything) the pull request will have.

Cheers,

Joseph

From: nvda-devel@groups.io <mailto:nvda-devel@groups.io>
<mailto:nvda-devel@groups.io> <nvda-devel@groups.io> On Behalf Of Leonard
de
Ruijter
Sent: Friday, November 22, 2019 9:56 AM
To: nvda-devel@groups.io <mailto:nvda-devel@groups.io>
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files
database to include add-on name/ID for easier comparison and for
future-proofing



Joseph,



For security reasons, I think the add-on database should also store a
sha256
hash of the add-on file, which can be provided and checked by NVDA after
downloading/updating the add-on. This can avoid installing add-ons from
malicious sources.

It might help to translate the proof of concept in an object definition or
a
definition of a database storage table, so we can see a real example of how
the metadata would be stored in the database. This makes it easier for
developers to give concrete feedback about the storage structure.



Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,



I'm considering the following modification to add-on files database, which
is used to store links to add-on files located on community add-ons website
and used by Add-on Updater add-on to detect new add-on releases:



Recently, there has been a growing sentiment within the NVDA community to
incorporate add-on updating functionality into NVDA screen reader. This is
more so now that more add-ons are being added to community add-ons website,
along with the urgency created by Python 3 transition and compatibility
issues surrounding it.



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.



For example, Windows 10 App Essentials is entered as "w10" in the add-on
files database. In the future, a dedicated key named "wintenApps" might be
added. And since several add-ons do have development version links, a
"-dev"
suffix can be added for new keys, which is how development version links
are
grouped under at the moment (for example, "wintenApps-dev"). In the end,
the
new add-on metadata database will feature a dedicated column for update
branches, with an add-on hosting at least one update branch.



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.



A few things to keep in mind:



* 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.
* This proposal is a proof of concept proposal and may change without
notice.
* 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.



Comments are appreciated.

Cheers,

Joseph






Brian's Mail list account
 

Well as long as everyone can understand what it actually means.
Example along comes a person who has an add on that only works in 2019.2.1 or earlier. He/she wants to stay on this version of nvda for that reason. Would this system only show that person add ons that are known to be compatible with that version of nvda, i.e. either legacy ones not made to work yet, or dual function ones where they work on both.


Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Friday, November 22, 2019 4:14 PM
Subject: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing


Hi all,



I'm considering the following modification to add-on files database, which
is used to store links to add-on files located on community add-ons website
and used by Add-on Updater add-on to detect new add-on releases:



Recently, there has been a growing sentiment within the NVDA community to
incorporate add-on updating functionality into NVDA screen reader. This is
more so now that more add-ons are being added to community add-ons website,
along with the urgency created by Python 3 transition and compatibility
issues surrounding it.



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.



For example, Windows 10 App Essentials is entered as "w10" in the add-on
files database. In the future, a dedicated key named "wintenApps" might be
added. And since several add-ons do have development version links, a "-dev"
suffix can be added for new keys, which is how development version links are
grouped under at the moment (for example, "wintenApps-dev"). In the end, the
new add-on metadata database will feature a dedicated column for update
branches, with an add-on hosting at least one update branch.



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.



A few things to keep in mind:



* 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.
* This proposal is a proof of concept proposal and may change without
notice.
* 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.



Comments are appreciated.

Cheers,

Joseph



Brian's Mail list account
 

I do think that there will at least for a while be folk staying on 2019.2.1, since not every add on will be ready, or indeed if from other sources, ever likely to be converted for the new nvda. Thus info on versions that an add on will work on is crucial so they do not overwrite things that work so to speak.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Leonard de Ruijter" <@leonardder>
To: <nvda-devel@groups.io>
Sent: Friday, November 22, 2019 6:34 PM
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing


Dear Joseph,


I'm not sure why we need a current version and new version string.

I would also say that it would help to identify all channels that are
available for an add-on with the same add-on name, i.e. don't
distinguish between wintenApps and wintenApps-dev at the identifier
levels, but allow adding multiple channels/versions per add-on.


Regards,

Leonard

Op 22-11-2019 om 19:05 schreef Joseph Lee:

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on
does have a field for it as part of the downloader class.

As for database schema, we have:

* Add-on ID/name (string)
* Friendly name (string
* Current version (string)
* New version (string)
* Minimum NVDA version (string)
* Last tested NVDA version (string)
* Hash (SHA256 minimum)
* Changelog (text)
* Download URL (URL)
* Author contact information (string and email address)

To answer James’s question: yes, designing the new database should be
done. But I think there should be a way to prototype it, and using
current infrastructure gives us an avenue to do so – in the end,
Add-on Updater is really a testbed for the pull request I’m working
on, so that add-on will have everything (or almost everything) the
pull request will have.

Cheers,

Joseph

*From:* nvda-devel@groups.io <nvda-devel@groups.io> *On Behalf Of
*Leonard de Ruijter
*Sent:* Friday, November 22, 2019 9:56 AM
*To:* nvda-devel@groups.io
*Subject:* Re: [nvda-devel] Add-on Updater proposal: modify add-on
files database to include add-on name/ID for easier comparison and for
future-proofing

Joseph,

For security reasons, I think the add-on database should also store a
sha256 hash of the add-on file, which can be provided and checked by
NVDA after downloading/updating the add-on. This can avoid installing
add-ons from malicious sources.

It might help to translate the proof of concept in an object
definition or a definition of a database storage table, so we can see
a real example of how the metadata would be stored in the database.
This makes it easier for developers to give concrete feedback about
the storage structure.

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

I’m considering the following modification to add-on files
database, which is used to store links to add-on files located on
community add-ons website and used by Add-on Updater add-on to
detect new add-on releases:

Recently, there has been a growing sentiment within the NVDA
community to incorporate add-on updating functionality into NVDA
screen reader. This is more so now that more add-ons are being
added to community add-ons website, along with the urgency created
by Python 3 transition and compatibility issues surrounding it.

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.

For example, Windows 10 App Essentials is entered as “w10” in the
add-on files database. In the future, a dedicated key named
“wintenApps” might be added. And since several add-ons do have
development version links, a “-dev” suffix can be added for new
keys, which is how development version links are grouped under at
the moment (for example, “wintenApps-dev”). In the end, the new
add-on metadata database will feature a dedicated column for
update branches, with an add-on hosting at least one update branch.

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.

A few things to keep in mind:

* 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.
* This proposal is a proof of concept proposal and may change
without notice.
* 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.

Comments are appreciated.

Cheers,

Joseph


derek riemer
 

I and Luke Davis were working on an addons database schema. We need to develop a website. maybe we should create a subgroup for this development.

On Fri, Nov 22, 2019 at 11:05 AM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on does have a field for it as part of the downloader class.

As for database schema, we have:

  • Add-on ID/name (string)
  • Friendly name (string
  • Current version (string)
  • New version (string)
  • Minimum NVDA version (string)
  • Last tested NVDA version (string)
  • Hash (SHA256 minimum)
  • Changelog (text)
  • Download URL (URL)
  • Author contact information (string and email address)

 

 

To answer James’s question: yes, designing the new database should be done. But I think there should be a way to prototype it, and using current infrastructure gives us an avenue to do so – in the end, Add-on Updater is really a testbed for the pull request I’m working on, so that add-on will have everything (or almost everything) the pull request will have.

Cheers,

Joseph

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Friday, November 22, 2019 9:56 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Joseph,

 

For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.

 

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph



--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com