fix(arch): missing images

doc/architecture.md

@@ -16,7 +16,7 @@ Your XOA is connected to all your hosts, or on the pool master only if you are u
 
 ## Xen Orchestra (XO)
 
-![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/xo-arch.jpg)
+![](./assets/xo-arch.jpg)
 
 Xen Orchestra itself is built as a modular solution. Each part has its role:
 - the core is "[xo-server](https://github.com/vatesfr/xo-server)", a daemon dealing directly with XenServer or XAPI capable hosts. This is where users are stored, and it's the center point for talking to your whole Xen infrastructure.
@@ -24,4 +24,4 @@ Xen Orchestra itself is built as a modular solution. Each part has its role:
 - "[xo-cli](https://github.com/vatesfr/xo-cli)" is a module allowing to send commands directly from the command line.
 
 
-We already have other modules around it (like the LDAP plugin for example). It allows to use this modular architecture to add further parts later. It's completely flexible, allowing us to adapt Xen Orchestra in every existing work-flow.
+We already have other modules around it (like the LDAP plugin for example). It allows to use this modular architecture to add further parts later. It's completely flexible, allowing us to adapt Xen Orchestra in every existing work-flow.

doc/xo-server.md

@@ -10,27 +10,27 @@ As a daemon, XO-server is always up. In this way, it can listen and record every
 
 Contrary to XenCenter, each Xen Orchestra's client is connected to one XO-Server, and not all the Xen servers. With a traditional architecture:
 
-![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/without-xo.jpg)
+![](./assets/without-xo.jpg)
 
 You can see how we avoid a lost of resources and bandwidth waste with a central point:
 
-![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/with-xo.jpg)
+![](./assets/with-xo.jpg)
 
 ### Events
 
 Legacy interfaces use the "pull" model, requesting data every "x" seconds:
 
-![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/noevent.jpg)
+![](./assets/noevent.jpg)
 
 It's **not scalable** and slow.
 
 With XO < 3.4, we used events in this way:
 
-![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/semievent.jpg)
+![](./assets/semievent.jpg)
 
 But interface was still lagging behind the server. With XO 3.4, we got a full event system, allowing instant display of what's happening on your infrastructure:
 
-![](https://github.com/vatesfr/xo/raw/master/doc/architecture/assets/fullevent.jpg)
+![](./assets/fullevent.jpg)
 
 ### A proxy for your hosts
 
@@ -84,4 +84,4 @@ An API is available to communicate directly with XO-Server. This part will be ex
 
 ### NodeJS under the hood
 
-[NodeJS](https://en.wikipedia.org/wiki/Nodejs) is a software platform for scalable server-side and networking applications. It's famous for its efficiency, scalability and its asynchronous capabilities. Exactly what we need! Thus, XO-server is written in JavaScript. 
+[NodeJS](https://en.wikipedia.org/wiki/Nodejs) is a software platform for scalable server-side and networking applications. It's famous for its efficiency, scalability and its asynchronous capabilities. Exactly what we need! Thus, XO-server is written in JavaScript.