Merge pull request #265 from gazebosim/architecture-ign-rename

[10] Architecture ign rename

Author: nkoenig

architecture.md

@@ -1,29 +1,29 @@
 # Gazebo Sim Architecture
 
-[Gazebo Sim](https://gazebosim.org/libs/gazebo) is an application entry-point of Ignition, generally encompassing the use of all other Ignition libraries.
+[Gazebo Sim](https://gazebosim.org/libs/gazebo) is an application entry-point of Gazebo, generally encompassing the use of all other Gazebo libraries.
 As an executable, it runs a simulation by launching two processes: the backend server process and frontend client process.
 
 The core functionality of Gazebo Sim is the client-server communication and the various plugins it loads to facilitate the simulation.
 Plugins are libraries that are loaded at runtime.
-They allow Gazebo Sim to utilize other Ignition libraries.
-There are many plugin types in the Ignition framework.
+They allow Gazebo Sim to utilize other Gazebo libraries.
+There are many plugin types in the Gazebo framework.
 For example, there are plugins that introduce new physics engines or rendering engines.
 However, for the purpose of this document, any mention of plugins is referring only to Gazebo Sim server and GUI plugins.
 
-Because they’re loaded at runtime, Ignition does not need to be recompiled to add or remove plugins.
-Gazebo Sim ships with many plugins by default ([Server plugins](https://gazebosim.org/api/gazebo/4.5/namespaceignition_1_1gazebo_1_1systems.html), [Ignition GUI plugins](https://gazebosim.org/api/gui/4.2/namespaceignition_1_1gui_1_1plugins.html), [Gazebo Sim GUI plugins]( https://gazebosim.org/api/gazebo/4.5/namespaceignition_1_1gazebo.html), and more), all of which are optional and can be removed by the user.
+Because they’re loaded at runtime, Gazebo does not need to be recompiled to add or remove plugins.
+Gazebo Sim ships with many plugins by default ([Server plugins](https://gazebosim.org/api/gazebo/4.5/namespaceignition_1_1gazebo_1_1systems.html), [Gazebo GUI plugins](https://gazebosim.org/api/gui/4.2/namespaceignition_1_1gui_1_1plugins.html), [Gazebo Sim GUI plugins]( https://gazebosim.org/api/gazebo/4.5/namespaceignition_1_1gazebo.html), and more), all of which are optional and can be removed by the user.
 Users can also add more plugins and even write their own plugins that will be compiled into library files.  
 
-Ignition libraries are modular.
+Gazebo libraries are modular.
 Plugins let Gazebo Sim utilize other libraries.
-For example, [Ignition Physics](https://gazebosim.org/libs/physics) and Gazebo Sim are independent of one another, so Gazebo Sim has a physics plugin that uses Ignition Physics as a library and incorporates Gazebo specifics, allowing Physics to be a system running in the simulation loop.
+For example, [Gazebo Physics](https://gazebosim.org/libs/physics) and Gazebo Sim are independent of one another, so Gazebo Sim has a physics plugin that uses Gazebo Physics as a library and incorporates Gazebo specifics, allowing Physics to be a system running in the simulation loop.
 
-The Ignition Physics library is only used in the physics plugin, not in other plugins nor in the core of Gazebo Sim.
+The Gazebo Physics library is only used in the physics plugin, not in other plugins nor in the core of Gazebo Sim.
 Some libraries are only used by one plugin, or one in each process (frontend and backend).
-However, some foundational libraries are used by all plugins, like [Ignition Common](https://gazebosim.org/libs/common) which provides common functionality like logging, manipulating strings, file system interaction, etc., to all plugins.
-Other such libraries include [Ignition Plugin](https://gazebosim.org/libs/plugin), [Ignition Math](https://gazebosim.org/libs/math), [SDFormat](https://gazebosim.org/libs/sdformat), and more.
+However, some foundational libraries are used by all plugins, like [Gazebo Common](https://gazebosim.org/libs/common) which provides common functionality like logging, manipulating strings, file system interaction, etc., to all plugins.
+Other such libraries include [Gazebo Plugin](https://gazebosim.org/libs/plugin), [Gazebo Math](https://gazebosim.org/libs/math), [SDFormat](https://gazebosim.org/libs/sdformat), and more.
 
-There are certain plugins in both the frontend and backend processes that are loaded by default in every version of Ignition.
+There are certain plugins in both the frontend and backend processes that are loaded by default in every version of Gazebo.
 Many other plugins are optional.
 One common optional plugin is the sensors plugin.
 Both optional and default plugins can be removed or added at any time; Gazebo Sim will continue to run with limited functionality.
@@ -46,8 +46,8 @@ For example, a user could write a system that applies force to an entity by sett
 The modification of entities and components is how server plugins communicate with each other.
 
 The entity component system is self-contained in Gazebo Sim, and systems act on entities and their components.
-Since other Ignition Libraries don't have direct knowledge/access to entities and components, other Ignition Libraries should be used in systems so that the server plugin can share entities (and their components) with these other Libraries.
-For example, the physics system shares entities and components with the Ignition Physics library in order to achieve physics effects on entities and components.
+Since other Gazebo Libraries don't have direct knowledge/access to entities and components, other Gazebo Libraries should be used in systems so that the server plugin can share entities (and their components) with these other Libraries.
+For example, the physics system shares entities and components with the Gazebo Physics library in order to achieve physics effects on entities and components.
 
 There is a loop running in the backend that runs the systems, where some systems are proposing changes to entities and their components, and other systems are handling and applying those changes.
 This is called the “simulation loop”.
@@ -61,15 +61,15 @@ The visualization of that data, however, is left up to the client side plugins.
 
 ## Communication process
 
-Any information that crosses the process boundary (whether back-to-front with scene broadcaster or front-to-back with user commands) has to go through [Ignition Transport](https://gazebosim.org/libs/transport), the communication library.
-Synchronization between processes is performed by scene broadcaster, a server-side Gazebo Sim plugin that uses the Ignition Transport and [Ignition Messages](https://gazebosim.org/libs/msgs) libraries to send messages from the server to the client.
-The messages themselves are provided by Ignition Messages, while the framework for creating the publishers and subscribers that exchange messages is from Ignition Transport.
+Any information that crosses the process boundary (whether back-to-front with scene broadcaster or front-to-back with user commands) has to go through [Gazebo Transport](https://gazebosim.org/libs/transport), the communication library.
+Synchronization between processes is performed by scene broadcaster, a server-side Gazebo Sim plugin that uses the Gazebo Transport and [Gazebo Messages](https://gazebosim.org/libs/msgs) libraries to send messages from the server to the client.
+The messages themselves are provided by Gazebo Messages, while the framework for creating the publishers and subscribers that exchange messages is from Gazebo Transport.
 
 The scene broadcaster system is responsible for getting the state of the world (all of the entities and their component values) from the ever-changing simulation loop running in the back end, packaging that information into a very compact message, and periodically sending it to the frontend process.
 Omitting the scene broadcaster, while possible, would mean not being able to visualize data on the frontend, which can be useful for saving computational power.
 
 In addition to state messages sent from the scene broadcaster to the client, the client can also make requests to the server using the user commands system (another backend plugin).
-It also utilizes the Ignition Transport and Ignition Messages libraries.
+It also utilizes the Gazebo Transport and Gazebo Messages libraries.
 The user commands system has services that can be requested by the frontend GUI to insert, delete, move (etc.) models, lights, and other entities, and will send responses back to the GUI acknowledging the receipt and execution of those requests.
 
 Several non-default plugins are able to send or receive messages to other processes outside of the server-client process.
@@ -79,9 +79,9 @@ One such process these plugins may communicate with, for example, is [ROS](https
 ## Frontend client process
 
 The client-side process, essentially the GUI, also comprises multiple plugins, some loaded by default, others that can be added, and all optional.
-All of the frontend plugins use the [Ignition GUI](https://gazebosim.org/libs/gui) library.
-The client itself also relies on Ignition GUI.
-There are visualization plugins that create the windows of the GUI, add buttons and other interactive features, and a 3D scene plugin that utilizes [Ignition Rendering](https://gazebosim.org/libs/rendering) that creates the scene the user sees.
+All of the frontend plugins use the [Gazebo GUI](https://gazebosim.org/libs/gui) library.
+The client itself also relies on Gazebo GUI.
+There are visualization plugins that create the windows of the GUI, add buttons and other interactive features, and a 3D scene plugin that utilizes [Gazebo Rendering](https://gazebosim.org/libs/rendering) that creates the scene the user sees.
 
 Frontend plugins typically communicate among themselves using [events](https://gazebosim.org/api/gui/4.2/namespaceignition_1_1gui_1_1events.html).
 Events are similar to messages, but they're processed synchronously.