Add-on update subsystem: preliminary design - a database back-end in partnership with a client UI
Locked
Add-on update subsystem: preliminary design - a database back-end in partnership with a client UI
 
|
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 |
Re: Add-on update subsystem: preliminary design - a database back-end in partnership with a client UI
|
|
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 |
| Free forum by Nabble | Edit this page |