[docs] Major edits to Remote Backends topic

* Renamed the file and updated the documentation to suit the Middleware feature instead

Task-number: AUTOSUITE-996
Change-Id: I214266c232ac69c98784cca07c347c83c76052e8
Reviewed-by: Dominik Holland <dominik.holland@pelagicore.com>
 

4 files changed, 163 insertions, 160 deletions

diff --git a/src/doc/qtautomotivesuite/src/qtautomotive-examples.qdoc b/src/doc/qtautomotivesuite/src/qtautomotive-examples.qdoc
index aab1de3..ca2338a 100644
--- a/src/doc/qtautomotivesuite/src/qtautomotive-examples.qdoc
+++ b/src/doc/qtautomotivesuite/src/qtautomotive-examples.qdoc
@@ -84,9 +84,9 @@
             \li \l{Qt IVI}
             \li Shows to use the Qt IVI Generator.
         \row
-            \li \l{Qt IVI Generator Remote Objects Example}
+            \li \l{Generate QtRemoteObjects based backends with the Qt IVI Generator}
             \li \l{Qt IVI}
-            \li Shows how to use the Qt IVI Generator to create remote backends.
+            \li Learn how to use the Qt IVI Generator to create QtRemoteObjects based backends.
         \row
             \li \l{QML Media Player Example}
             \li \l{Qt IVI}
diff --git a/src/ivicore/doc/src/examples-qface-ivi-remote.qdoc b/src/ivicore/doc/src/examples-qface-ivi-remote.qdoc
index 6694f20..6bad1e7 100644
--- a/src/ivicore/doc/src/examples-qface-ivi-remote.qdoc
+++ b/src/ivicore/doc/src/examples-qface-ivi-remote.qdoc
@@ -28,34 +28,37 @@
 
 /*!
 \example ivicore/qface-ivi-remote
-\brief This Example shows how to use the Qt IVI Generator to create remote backends.
+\brief Learn how to use the Qt IVI Generator to create QtRemoteObjects based backends.
 \ingroup qtivicore-examples
-\title Qt IVI Generator Remote Objects Example
+\title Generate QtRemoteObjects based backends with the Qt IVI Generator
 \image examples_qface_ivi_remote.png
 
 \section1 Introduction
 
-This example shows how to create a remote backend and the client side components
-using the Qt IVI Generator. The communication between the client and server is done with
-QtRemoteObjects. Based on a single qface IDL file, it will generate:
+This example shows how to generate a Middleware API, a Middleware Backend, and the
+corresponding Middleware Service using the Qt IVI Generator. The communication between
+the backend and the service is done with QtRemoteObjects as the IPC.
+
+We use a single QFace IDL file to generate:
 
 \list
 \li a shared library with the front-end code
-\li a back-end plugin that implements a client for connecting to the server
-\li a server that runs the actual remote backend logic
-\li a demo application that connects to the server and provides and UI for using the service
+\li a backend plugin that implements a client to connect to the server
+\li a server that runs the actual backend logic in a separate server process
+\li a demo application that connects to the server and provides a UI to use the service
 \endlist
 
-In addition to the generated C++ code, the backend-plugin and the server contain also an
-intermediate .rep -file that is further processed by Qt’s replica compiler to produce the actual
-source and replica classes.
+In addition to the generated C++ code, the backend plugin and the server also contain an
+intermediate \c{.rep} file that is further processed by the
+\l [QtRemoteObjects] {Qt Remote Objects Compiler} {replica compiler} to produce the source and
+replica classes.
 
 \section2 Walkthrough
 
-The IDL file used in the example represents an imaginary remote service for processing data . It
-contains a single interface with a single property and a single method.
+The IDL file used in the example represents an imaginary remote service for processing data. It
+contains a single interface with one property and one method.
 
-First we need to define which \e module we want to describe. The \e module acts as a namespace,
+First, we need to define which \e module we want to describe. The \e module acts as a namespace,
 because the IDL file can contain multiple interfaces.
 
 \snippet ../../../../examples/ivicore/qface-ivi-remote/example-ivi-remote.qface 0
@@ -64,107 +67,106 @@ The most important part is the definition of the \e interface.
 
 \snippet ../../../../examples/ivicore/qface-ivi-remote/example-ivi-remote.qface 1
 
-In this case, we define an \e interface named \b ProcessingService consisting of a single property
-and a single method. Every property and method definition needs to contain at least a type and a
-name. Most of the basic types are builtin and can be found in the \l {QFace IDL syntax} {reference}.
+In this case, we define an \e interface named \b ProcessingService with one property and one
+method. Every property and method definition needs to contain at least a type and a name. Most of
+the basic types are built-in and can be found in the \l{QFace IDL Syntax}.
 
 
 \section1 Frontend library
 
-Now we want to use the IVI Generator to generate a shared library containing a C++ implementation of
-our module and its interface. For this, the \e frontend template is used. This will generate a class
-derived from \c {QIviAbstractZonedFeature} including all the specified properties. The generated
-library will use the \l {Dynamic Backend System} from QtIviCore and by that provide an easy way to
-change the behavior implementations.
+Next, we use the IVI Generator to generate a shared library containing a C++ implementation of our
+module and its interface; particularly the \e frontend template. This template generates a class
+derived from \l{QIviAbstractFeature}, that includes all of the specified properties. The
+generated library uses the \l{Dynamic Backend System} from QtIviCore, consequently providing an
+easy way to change how the behavior is implemented.
 
-In order to call the autogenerator for our shared library, the qmake project file needs to use the
-\e ivigenerator qmake feature. The following snippet shows how it can be added:
+To call the autogenerator for our shared library, the qmake project file needs to use the
+\c ivigenerator qmake feature:
 
 \snippet ../../../../examples/ivicore/qface-ivi-remote/frontend/frontend.pro 1
 
-By adding \e ivigenerator to the \e CONFIG variable, the \e ivigenerator feature file will be
-loaded and interpret the \e QFACE_SOURCES variable similar to \e SOURCES variable of normal qmake
-projects.
-Activating the qmake feature using the \e CONFIG variable has the disadvantage that it doesn't
-report any errors if the feature is not available. Because of this, it is encouraged to use the
-following additional code to report errors:
+By adding \c ivigenerator to the \c CONFIG variable, the \c ivigenerator feature file is loaded and
+interprets the \c QFACE_SOURCES variable, similar to the \c SOURCES variable in regular qmake
+projects. However, activating the qmake feature via the \c CONFIG variable has one disadvantage: if
+the feature is not available, no errors are reported. We recommend using the following additional
+code to report errors:
 
 \snippet ../../../../examples/ivicore/qface-ivi-remote/frontend/frontend.pro 0
 
-The other part of the project file is a normal library setup which is supposed to work on
-Linux, macOS and Windows.
+The remaining part of the project file is a normal library setup that works on Linux, macOS, and
+Windows.
 
 
-\section1 RemoteObjects Backend Plugin
+\section1 QtRemoteObjects Backend Plugin
 
-As mentioned above, the \e frontend library will use the \l {Dynamic Backend System}. This means
+As mentioned above, the \e frontend library uses the \l{Dynamic Backend System}. This means
 that for the library to provide some functionality, we also need a \e backend plugin. The generated
-plugin here will work as a client that connects to the server using the Qt Remote Objects. The qmake
-integration works in the same way, but it is using the \e QFACE_FORMAT variable to tell the
-ivigenerator to use a different generation template, \e backend_qtro:
+plugin here works as a client that connects to the server using Qt Remote Objects. The qmake
+integration works in the same way, but it uses the \e QFACE_FORMAT variable to tell the
+\c ivigenerator to use a different generation template, \e backend_qtro:
 
 \snippet ../../../../examples/ivicore/qface-ivi-remote/backend_qtro/backend_qtro.pro 2
 
-The generated backend plugin code is usable as is, and doesn't require further changes by the
-developer. As we want to generate a plugin instead of a plain library, we need to instrument qmake
-to do so by adding \e plugin to the \e CONFIG variable. For the plugin to compile correctly it needs
-to get the backend interface header from the previously created library. As this header is also
-generated, it is not part of our source tree, but part of the build tree. We do this by adding it to
-the include path using the following construct:
+The generated backend plugin code is usable as is, and doesn't require any further change. As we
+want to generate a plugin instead of a plain library, we need to instruct qmake to do so by adding
+\c plugin to the \c CONFIG variable. For the plugin to compile correctly it needs to get the
+backend interface header from the previously created library. But this header is also generated, so
+it's not part of our source tree, but part of the build tree. To provide the backend interface
+header, we add it to the include path using the following construct:
 
 \snippet ../../../../examples/ivicore/qface-ivi-remote/backend_qtro/backend_qtro.pro 1
 
 Most of the code in the backend plugin is generated by the IVI Generator, but some of it is
-generated by the Qt's remote object compiler (repc). This is achieved by IVI Generator producing an
-intermediate .repc file that is further processed by the repc compiler. The repc is called via the
-generated .pri file, found in the build directory (notice, that you have to call qmake on the
-project at least once to have the generated files available).
+generated by the Qt's Remote Object Compiler, \c repc. To achieve this, the IVI Generator produces
+an intermediate \c{.repc} file that's further processed by the \c repc compiler. This compiler is
+called via the generated \c{.pri} file, found in the build directory. Notice that you have to call
+qmake on the project, at least once to have the generated files available.
 
 
-As our application doesn't know about the existence of our backend plugin, we need to put this
-plugin in a folder where our application searches for plugins. By default Qt either search in the
-\b plugins folder within Qt's installation directory or in the current working directory of the
-application. For QtIvi plugins to be found, they need to be provided within a \b qtivi sub-folder.
-This is achieved automatically by adding the following line to our backend project file:
+Our application doesn't know about the existence of our backend plugin, so we need to put this
+plugin in a folder where the application typically looks for plugins. By default, Qt either
+searches in the \b plugins folder within its installation directory or in the application's current
+working directory. For QtIvi plugins to be found, they need to be provided within a \b qtivi
+sub-folder. Add the following line to the backend project file, as follows:
 
 \snippet ../../../../examples/ivicore/qface-ivi-remote/backend_qtro/backend_qtro.pro 0
 
 
 \section1 RemoteObjects Server
 
-The server is an independent, GUIless application that contains the actual business logic of our
-backend and hence needs to have most of its implementation written by the developer. Nevertheless,
-the generator produces some code to simplify the development. We can generate server side code by
-using the IVI Generator with \e server_qtro template:
+The server is an independent, GUI-less application that contains the backend's business logic, and
+we need to write most of its implementation. Nevertheless, the generator produces some code to
+simplify the development. We can generate server side code by using the IVI Generator with the
+\e server_qtro template:
 
 \snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/server_qtro.pro 0
 \dots 0
 \snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/server_qtro.pro 1
 
 To use the generated remote source, we need to inherit from one of the classes defined in the
-generated rep_processingservice_source.h file. In this example we implement our servers logic in the
-ProcessingService class and use the ProcessingServiceSimpleSource as the base class:
+generated \c rep_processingservice_source.h file. In this example, we implement our server's
+logic in the \c ProcessingService class and use the \c ProcessingServiceSimpleSource as the base
+class:
 
 \code
 // server_qtro/processingservice.h
 \endcode
 \snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/processingservice.h 0
 
-Please notice, that the base class contains already the definitions for property accessors, but any
-custom method or slot needs to be overridden and defined by the developer. Our implementation of the
-process function merely counts and returns the length of the passed data and updates the lastMessage
-property:
+Note that the base class already has the definitions for property accessors, but any custom
+method or slot needs to be overridden and defined. Our implementation of the process function
+merely counts and returns the length of the data passed and updates the \c lastMessage property:
 
 \code
 // server_qtro/processingservice.cpp
 \endcode
 \snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/processingservice.cpp 0
 
-In order to make the class \b ProcessingService accessible remotely, we need to share it. This is
-done with the QRemoteObjectNode::enableRemoting() function. The generated Core class provides a
-preconfigured instance of a remotenode that is used for the remoting. In order for the plugin to
-connect to the right object, use an identifier in the format ModuleName.InterfaceName, which in this
-case is "Example.IVI.Remote.ProcessingService". All this is done in the main()-function, along with
+To make the \c ProcessingService class accessible remotely, we need to share it via the
+QRemoteObjectNode::enableRemoting() function. The \c Core class generated provides a preconfigured
+instance of a \c remotenode that is used for the remoting. For the plugin to connect to the right
+object, use an identifier in the format "ModuleName.InterfaceName", which in our case is
+"Example.IVI.Remote.ProcessingService". All this is done in the \c main() function, along with
 the start of the main event loop:
 
 \code
@@ -172,23 +174,23 @@ the start of the main event loop:
 \endcode
 \snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/main.cpp 0
 
-Implementing a service that is accessible remotely is as simple as that; use the properties as usual
-and provide the method implementations. The QtRemoteObjects library takes care of the communication.
+This is all you need to do to implement a service that is accessible remotely; use the properties
+as usual and provide the method implementations. The QtRemoteObjects library takes care of the
+communication.
 
 
 \section1 Demo Client Application
 
-The demo application presents a simple QML GUI for using the remote service over
-the generated interface.
+The demo application presents a simple QML GUI to use the remote service over the generated
+interface.
 
 As we do not provide a QML plugin, the application needs to link to the generated frontend library
-and call the \e {RemoteModule::registerTypes} and \e {RemoteModule::registerQmlTypes} methods
-that are generated in the module singleton to register all autogenerated interfaces and types with
-the QML engine.
+and call the \c{RemoteModule::registerTypes} and \c{RemoteModule::registerQmlTypes} methods that
+are generated in the module singleton to register all autogenerated interfaces and types with the
+QML engine.
 
-In our QML application, we still need to import the module using the same module uri which is used
-in the qface file. Afterwards the interface can be instantiated like any other
-QML item.
+In our QML application, we still need to import the module using the same module URI which is used
+in the QFace file. Afterwards the interface can be instantiated like any other QML item.
 
 \code
 // demo/main.qml
@@ -196,17 +198,17 @@ QML item.
 \snippet ../../../../examples/ivicore/qface-ivi-remote/demo/main.qml 0
 \dots 0
 
-Every method call that is made through a generated API, is asynchronous. This means,
-that instead of directly returning a return value, a \c {QIviPendingReply} object is returned.
-Using the \l QIviPendingReply::then() method on the returned object, we may assign callbacks to it
-that are called when the method call has been successfully finished or if it has failed.
+Every method call that is made through a generated API, is asynchronous. This means that instead
+of directly returning a return value, a QIviPendingReply object is returned. Using the
+\l QIviPendingReply::then() method on the returned object, we may assign callbacks to it that are
+called when the method call has been successfully finished; or if it has failed.
 
 \code
 // demo/main.qml
 \endcode
 \snippet ../../../../examples/ivicore/qface-ivi-remote/demo/main.qml 1
 
-In case of properties, we just use bindings as usual:
+In case of properties, we use bindings as usual:
 
 \code
 // demo/main.qml
@@ -215,8 +217,8 @@ In case of properties, we just use bindings as usual:
 
 \section1 Running the Example
 
-In order to see the whole functionality of the demo, run both the server and the demo application
-at the same time. You may leave the server running and restart the application, or vice versa,
+To see the demo's entire functionality, run both the server and the demo application
+simultaneously. You may leave the server running and restart the application, or vice versa,
 to see that the reconnection works. Run the demo application alone without the server running,
 to test how the remote method call fails when there is no connection.
 
diff --git a/src/ivicore/doc/src/ivigenerator/ipc-integration.qdoc b/src/ivicore/doc/src/ivigenerator/ipc-integration.qdoc
new file mode 100644
index 0000000..50e4c0d
--- /dev/null
+++ b/src/ivicore/doc/src/ivigenerator/ipc-integration.qdoc
@@ -0,0 +1,75 @@
+/****************************************************************************
+**
+** Copyright (C) 2019 Luxoft Sweden AB
+** Copyright (C) 2018 Pelagicore AG
+** Contact: https://www.qt.io/licensing/
+**
+** This file is part of the documentation of the QtIvi module of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:FDL-QTAS$
+** Commercial License Usage
+** Licensees holding valid commercial Qt Automotive Suite licenses may use
+** this file in accordance with the commercial license agreement provided
+** with the Software or, alternatively, in accordance with the terms
+** contained in a written agreement between you and The Qt Company.  For
+** licensing terms and conditions see https://www.qt.io/terms-conditions.
+** For further information use the contact form at https://www.qt.io/contact-us.
+**
+** GNU Free Documentation License Usage
+** Alternatively, this file may be used under the terms of the GNU Free
+** Documentation License version 1.3 as published by the Free Software
+** Foundation and appearing in the file included in the packaging of
+** this file. Please review the following information to ensure
+** the GNU Free Documentation License version 1.3 requirements
+** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+/*!
+\page ipc-integration.html
+\title Qt IVI Inter-Process Communication Integration
+
+An Inter-Process Communication (IPC) enables APIs to be split into multiple processes. Each process
+runs independently, sometimes on a separate host machine, and the communication is done using an
+IPC. The IPC also allows for multiple clients, or frontends to access the same service. These
+frontends can be, for example, the main Infotainment System UI, or different applications that run
+within the UI or mobile devices.
+
+\section1 Benefits of using an IPC
+
+An IPC enables functionality distribution and information sharing, between multiple processes or
+even between multiple host machines. Separate processes improve the overall reliability of a
+complex system and make it possible to separate computation-intensive code from the UI code.
+Additionally, backends that use an IPC can be accessible via multiple frontend points, be it the
+central UI, separate applications, or even mobile devices or third party applications.
+
+Combined with QtIvi's \l{Use the Generator}{automatic code generation} and uniform feature loading,
+developing distributed features requires less development overhead, with more interchangeability
+and transparency for the UI code.
+
+\section1 Qt Remote Objects
+
+The Qt IVI Generator makes it possible to generate Middleware Backends that utilize the
+QtRemoteObjects module. The client-side code is generated as a QtIvi backend plugin and and as a
+a Middleware Service, either a server stub or a full simulation server. The client is generated
+using the \l{backend-qtro-template} {backend_qtro} template; the server using the
+\l{server-qtro-template} {server_qtro} template. Both the plugin and the server contain generated
+C++ code and an intermediate \c{.rep} file that is further processed by Qt’s
+\l [QtRemoteObjects] {Qt Remote Objects Compiler} {replica compiler} to produce the actual source
+and replica classes.
+
+The generated plugin is loaded and used in the same way as other QtIvi plugins and is
+interchangeable with any other backend implementation with the same API. Since all method calls
+over QtIvi feature interfaces are asynchronous, the use of a QtRemoteObjects based backend is
+similar to any other type of backend.
+
+The generated plugin is buildable and usable as-is; you don't have to make any changes. Your task
+is then to implement the intended functionality on the server-side. To help you get started with
+the server, there's a generated class included, which initializes the connection. All connection
+parameters to the plugin and to the server are passed over a config file, either in a default
+location or at a user-specified path.
+
+For a steb-by-step introduction to remote backends, see
+\l {ivicore/qface-ivi-remote}{Generate QtRemoteObjects based backends with the Qt IVI Generator}.
+
+*/
diff --git a/src/ivicore/doc/src/ivigenerator/remotebackends.qdoc b/src/ivicore/doc/src/ivigenerator/remotebackends.qdoc
deleted file mode 100644
index db53a65..0000000
--- a/src/ivicore/doc/src/ivigenerator/remotebackends.qdoc
+++ /dev/null
@@ -1,74 +0,0 @@
-/****************************************************************************
-**
-** Copyright (C) 2019 Luxoft Sweden AB
-** Copyright (C) 2018 Pelagicore AG
-** Contact: https://www.qt.io/licensing/
-**
-** This file is part of the documentation of the QtIvi module of the Qt Toolkit.
-**
-** $QT_BEGIN_LICENSE:FDL-QTAS$
-** Commercial License Usage
-** Licensees holding valid commercial Qt Automotive Suite licenses may use
-** this file in accordance with the commercial license agreement provided
-** with the Software or, alternatively, in accordance with the terms
-** contained in a written agreement between you and The Qt Company.  For
-** licensing terms and conditions see https://www.qt.io/terms-conditions.
-** For further information use the contact form at https://www.qt.io/contact-us.
-**
-** GNU Free Documentation License Usage
-** Alternatively, this file may be used under the terms of the GNU Free
-** Documentation License version 1.3 as published by the Free Software
-** Foundation and appearing in the file included in the packaging of
-** this file. Please review the following information to ensure
-** the GNU Free Documentation License version 1.3 requirements
-** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
-** $QT_END_LICENSE$
-**
-****************************************************************************/
-/*!
-\page remotebackends.html
-\title QtIvi Remote Backends
-
-The Qt IVI Generator makes it possibile to create remote backends that utilize the
-QtRemoteObjects module.
-
-A remote backend is a process that runs independently, sometimes on a separate host machine,
-that can be accessed by multiple clients, or frontends.
-
-These frontends can be, for example, the main Infotainment System UI, or different applications that
-run within the UI or mobile devices.
-
-\section1 Motivation
-
-The purpose of having remote backends is to enable the distribution of functionality and the sharing
-of information. This may be between multiple processes and even between multiple host machines.
-Separate processes improve the overall reliability of a complex system and make it possible to
-separate computationally intensive code from the UI code. Additionally, remote backends can be
-accessible by multiple frontend points, be it the central UI, separate applications or even mobile
-devices or third party applications.
-Combined with the automatic generation of code and uniform feature loading of QtIvi, the development
-of distributed features comes with a minimal development overhead and interchangeability and
-transparency on the UI code side.
-
-\section1 Code Generation
-
-The remote objects generator produces client side code as a QtIvi backend plugin and a remote server
-stub. The client is generated using the \l {backend-qtro-template}{backend_qtro} template and the s
-erver using the \l {server-qtro-template}{server_qtro} template. Both the plugin and the server
-contain generated c++ code and an intermediate .rep -file that is further processed by Qt’s
-\l [QtRemoteObjects] {Qt Remote Objects Compiler} {replica compiler} to produce the actual source
-and replica classes.
-
-The generated plugin is loaded and used as any other QtIvi plugin and is interchangeable with any
-other backend implementation with the same API. As all method calls over QtIvi feature interfaces
-are asynchronous, the use of a remote backend is similar to any other type of backend.
-
-The generated plugin is buildable and usable as it is, and does not require further changes by the
-developer. The task of the developer will be then to implement the intended functionality at the
-server side. To support getting started with the server, there is a generated class that initializes
-the connection. All connection parameters to the plugin and to the server are passed currently over
-a config file, either in a default location or at an user specified path.
-
-For a steb-by-step introduction to remote backends, see the \l {ivicore/qface-ivi-remote}{Remote Backend Example}.
-
-*/