diff --git a/doc/source/roadmap.rst b/doc/source/roadmap.rst
index ae9228a..4179c3d 100644
--- a/doc/source/roadmap.rst
+++ b/doc/source/roadmap.rst
@@ -2,11 +2,11 @@
 Project's road-map
 ==================
 
-Please take into account that most of the items here are proposals.
+Please take into account that most of the items here are *proposals*.
 I get some ideas talking with customers, some ideas are my own thoughts.
 There is no plan when these features will be implemented - this depends
 if enough interest is raised and if there will be contribution to the project
-in terms of patches or financial contribution to develop a feature.
+in terms of patches or financial contributions to develop a feature.
 
 Thanks again to all companies that have supported my work up now and to
 everybody who has contributed to the project, let me bring SWUpdate
@@ -20,17 +20,42 @@ SWUpdate suitable for a large number of products.
 This will help to build a community around the project
 itself.
 
+Disk partitions
+===============
+
+SWUpdate is able to set and handle UBI partitions, while it requires external
+tools to set up disk partitions (sfdisk / fdisk). Because an update should be self-contained, it is
+desirable that SWUpdate will integrate the code to be able to set up partitions
+configured in sw-descriptions even for disks (eMMC / SD / Hard-disks).
+This will let to use `partitions` inside sw-description to set up disk partitions
+and not only UBI volumes, and add further features as restoring configuration data and so on.
+
+Support for further compressors
+===============================
+
+SWUpdate supports image compressed with zlib. This is a compromise between compression rate
+and speed to decompress the single artifact. To reduce bandwidth or for big images, a stronger
+compressor could help. Adding a new compressor must be careful done because it changes the
+core of handling an image.
+
+System Update
+=============
+
+Not just the single device, but several devices connected together to build a more
+complex system should be updated at once in an atomic way. The installation and the
+restart of the system must be done in a controlled way.
+
 SWUpdate as Updater Gateway
-===========================
+---------------------------
 
 This feature was introduced with the "swuforward" handler. It is already
 possible to update a tree of devices if each of them runs SWUpdate. This
-feature is already implemented in SWUpdate for embedded linux.
+feature is already implemented in SWUpdate for embedded Linux.
 
 Anyway, a lot of embedded devices have small processors and maybe not a full
 blown OS. Ensuring security for all of them can be a risk, and it is
 easier to make sure on a single device. If the device running SWUpdate is
-acting as gateway, it can translate protocols from backend and send
+acting as gateway, it can translate protocols from back-end and send
 package updates to the connected small devices.
 
 One example could be if SWUpdate runs as MQTT-broker and takes updates
@@ -40,6 +65,15 @@ suricatta to do this.
 One other examples is using LWM2M. The gateway should be generic enough
 to allow to add further protocols in future.
 
+Enhance swuforward handler
+--------------------------
+
+This handler requires that SWUpdate-slaves connected to the master run the Web-server
+with old API using a poll mechanism to check the update's progress. This forbids
+to run at the same time SWUpdate as slave and with the Website, because in old mode
+the website is not available anymore. If swuforward will switch to Web-sockets and implements
+the newer API, this constraint can be removed.
+
 Binary delta updates
 ====================
 
@@ -53,6 +87,15 @@ and the feature should not introduce leaks and make the system
 more vulnerable. It is accepted that different technologies could be added,
 each of them solves a specific use case for a delta update.
 
+SWUpdate is already able to perform delta updates based on librsync library. This is
+currently a good compromise to reduce complexity. Anyway, this helps in case of
+small changes, and it is not a general solution between two generic releases.
+A general approach could be to integrate SWUpdate with CA-Sync to allow a delta upgrade
+from any release. First proof of concept shows that changes in both SWUpdate and CA-Sync
+are required to be conform with requirements and security concepts in SWUpdate. A design
+just using CA-Sync as external fetcher without integration in SWUpdate  breaks
+SWUpdate's security concept.
+
 Integration in Linux distro
 ===========================
 
@@ -70,11 +113,11 @@ New Handlers
 Users develop own custom handlers - I just enforce and encourage everyone
 to send them and discuss how to integrate custom handler in mainline.
 
-A handler to update a microcontroller connected via UART is introduced.
+A handler to update a micro-controller connected via UART is introduced.
 It could be enhanced to support other interfaces (SPI for example).
 
 Some ideas for new handlers:
-        - handlers to update microcontrollers
+        - handlers to update micro-controllers
         - FPGA updater for FPGA with Flash
         - Package handler to install packages (ipk, deb)
           Packages can be inserted into the SWU and the atomicity is
@@ -90,11 +133,11 @@ The flash handler for raw-devices (mainly NOR flashes) does not allow to
 stream the image and an error is reported if "installed-directly" is set.
 The handler can be extended to stream images.
 
-Handlers installable as plugin at runtime
+Handlers install-able as plugin at runtime
 -----------------------------------------
 
 The project supports Lua as script language for pre- and postinstall
-script. It will be easy to add a way for installing a handler at runtime
+script. It will be easy to add a way for installing a handler at run-time
 written in Lua, allowing to expand SWUpdate to the cases not covered
 in the design phase of a product.
 
@@ -109,31 +152,47 @@ a unauthenticated handler cannot run.
 Support for evaluation boards
 =============================
 
-New is meta-swupdate-boards - examples regarding evaluation boards are
-put there. Currently, there are examples for Beaglebone Black,
-Raspberri PI 3 and Wandboard. Maybe some more boards ? Patches welcome.
+meta-swupdate-boards contains examples with evaluation boards.
+Currently, there are examples using Beaglebone Black,
+Raspberri PI 3 and Wandboard. The repo is a community driven project:
+patches welcome.
 
-Backend support (suricatta mode)
+Back-end support (suricatta mode)
 ================================
 
-Backend: Hawkbit Offline support
+Back-end: check before installing
+--------------------------------
+
+In some cases (for example, where bandwidth is important), it is better to check
+if an update must be installed instead of installing and performs checks later.
+If SWUpdate provides a way to inform a checker if an update can be accepted
+before downloading, a download is only done when it is really necessary.
+
+Back-end: Hawkbit Offline support
 --------------------------------
 
 There are several discussions on Hawkbit's ML about how to synchronize
-an offline update (done locally or via the internal Webserver) with
+an offline update (done locally or via the internal Web-server) with
 the Hawkbit's server. Currently, Hawkbit thinks to be the only one
 deploying software. Hawkbit DDI API should be extended, and afterwards
 changes must be implemented in SWUpdate.
 
-Backend: Consolidate "general server"
+Back-end: Consolidate "general server"
 -------------------------------------
 
 A second OTA server was introduced with 2018.11, but there is not
 an open source solution for a server. Anyway, the very simple interface
 of the "general server" can be used by anyone to introduce an own server
-instead of a more complicate solution with a backend like Hawkbit.
+instead of a more complicate solution with a back-end like Hawkbit.
+
+Back-end: support for generic down-loader 
+---------------------------------------
+
+SWUpdate in down-loader mode works as one-shot: it simply try to download a SWU
+from a URL. For simple applications, it could be moved into `suricatta` to detect
+if a new version is available before downloading and installing.
 
-Backend: support for Mender
+Back-end: support for Mender
 ---------------------------
 
 There was several discussion how to make a stronger collaboration between
@@ -157,7 +216,7 @@ A first version of SWUpdate-GUI was released with a base set of features. The go
 is to have a low footprint compared to GUI developed with state of art frameworks. 
 This lets to still have a rescue that fits in small devices.
 
-Test and Continuos Integration
+Test and Continuous Integration
 ==============================
 
 The number of configurations and features in SWUpdate is steadily increasing and
@@ -171,5 +230,4 @@ and tested on real hardware.
 Documentation
 =============
 
-Documentation should be improved. There is just a little documentation for meta-swupdate
-how to set it up with different configurations.
+Documentation is a central point in SWUpdate - maintaining it up to date is a must in this project. 
