Add-on update subsystem: preliminary design - a database back-end in partnership with a client UI

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Add-on update subsystem: preliminary design - a database back-end in partnership with a client UI

Joseph Lee

Hi everyone,

 

For the past few weeks, one of the most talked about items in the add-ons community was ability to check for add-on updates (issue 3208). After talking to some add-on authors, I and Derek Riemer came up with a preliminary design as follows:

 

Overall design: client/server – a partnership between a database and a client UI, along with transport links utilizing a protocol similar to NVDA Core’s update check facility is envisioned. In order for this to work, a scalable database is employed on the add-ons server that stores information about add-ons, including add-on key, version, download URL and download stats (if asked). The overall procedure is similar to NVDA Core’s update check facility and will be carried out as follows:

 

1.       An add-on comes to add-ons server (after being reviewed).

2.       Add-on is installed on the client side (NVDA user).

3.       The add-ons database stores information about the add-on (server side).

4.       Client checks for add-on updates (automatic or manual), using a dictionary.

5.       Server (database) returns “true” if an update is available, and if so, allows the client to fetch the results.

6.       Client chooses an option (if yes, add-on will be downloaded; if not, the version will be added to “do not ask” list).

7.       This process repeats.

 

Issues:

·         What: among various database packages, we should choose a robust one that scales to the needs of the add-ons community. Note that the database must run under Ubuntu, as this is the distro in use.

·         When: anyone would like to help out when the time permits?

·         How: how should add-on authors, community members, NV Access and others take part in this project?

·         Security: ideally, https should be employed.

·         Scope: Jamie mentioned in issue 3208 that this should be limited to add-ons posted on our community add-ons website (addons.nvda-project.org).

·         Other issues that may arise.

 

Issue link:

https://github.com/nvaccess/nvda/issues/3208

 

Thanks.

Cheers,

Joseph


------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Add-on update subsystem: preliminary design - a database back-end in partnership with a client UI

Isaac Porat

Hi Joseph


For some reason or other some add-ons are not part of the official add-ons repository.  For example I distribute add-ons together with two of my programs, it means that these add-on needs to be matched with my software version and are therefore downloaded as part of my packages.


Other add-ons are experimental etc.

I propose that you make a backwards compatible provision in your system to accommodate these add-ons; for example if an add-on is not in the database a clear message would tell users about this when they try to update.  Another possibility is that supported add-ons would have an additional metadata to indicate that they can be updated automatically.

Thanks
Isaac
                                               

On 28/07/2016 21:05, Joseph Lee wrote:
Hi everyone,

 

For the past few weeks, one of the most talked about items in the add-ons
community was ability to check for add-on updates (issue 3208). After
talking to some add-on authors, I and Derek Riemer came up with a
preliminary design as follows:

 

Overall design: client/server - a partnership between a database and a
client UI, along with transport links utilizing a protocol similar to NVDA
Core's update check facility is envisioned. In order for this to work, a
scalable database is employed on the add-ons server that stores information
about add-ons, including add-on key, version, download URL and download
stats (if asked). The overall procedure is similar to NVDA Core's update
check facility and will be carried out as follows:

 

1.       An add-on comes to add-ons server (after being reviewed).

2.       Add-on is installed on the client side (NVDA user).

3.       The add-ons database stores information about the add-on (server
side).

4.       Client checks for add-on updates (automatic or manual), using a
dictionary.

5.       Server (database) returns "true" if an update is available, and if
so, allows the client to fetch the results.

6.       Client chooses an option (if yes, add-on will be downloaded; if
not, the version will be added to "do not ask" list).

7.       This process repeats.

 

Issues:

*         What: among various database packages, we should choose a robust
one that scales to the needs of the add-ons community. Note that the
database must run under Ubuntu, as this is the distro in use.

*         When: anyone would like to help out when the time permits?

*         How: how should add-on authors, community members, NV Access and
others take part in this project?

*         Security: ideally, https should be employed.

*         Scope: Jamie mentioned in issue 3208 that this should be limited
to add-ons posted on our community add-ons website
(addons.nvda-project.org).

*         Other issues that may arise.

 

Issue link:

https://github.com/nvaccess/nvda/issues/3208

 

Thanks.

Cheers,

Joseph




------------------------------------------------------------------------------


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel