documentation: re-organize doc

Change-Id: I9c2bf00dd7734889646f73db55cb475bd2cc4417

developer/going-further/index.rst

+##############
+Going further
+##############
+
+This part of the documentation is dedicated to developers who want to dig
+some more specific topics about Jami.
+
+.. toctree::
+   :maxdepth: 1
+
+   choosing-crf-value-for-encoder
+   delivery-status
+   important-rfcs
+   location-sharing
+   message-displayed-status
+   setting-up-your-own-turn-server
\ No newline at end of file

developer/index.rst

@@ -10,39 +10,8 @@ designed and how its various parts work together.
 .. toctree::
    :maxdepth: 1
 
-   introduction
-   apis-of-jami
-   account-management
-   contact-management
-   design-process
-   swarm
-   drt
-   calls
-   file-transfer
-   message-displayed-status
-   setting-up-your-own-turn-server
-   synchronizing-profiles
-   submitting-your-first-patch
-   debugging-tools
    feature-requests
-   connection-manager
-   delivery-status
-   calls-in-swarm
-   conference-protocol
-   synchronization-protocol
-   important-rfcs
-   improving-quality-of-jami
-   libjamiclient-documentation
-   name-server-protocol
-   protocol
-   release-process
-   technical-overview
-   jami-identifiers
-   choosing-crf-value-for-encoder
-   banned-contacts
-   coding-style
-   qt-qml-coding-style
-   qt-qml-testing-tools
-   working-with-gerrit
-   working-with-gerrit-fr
-   location-sharing
+   new-developers/index
+   jami-concepts/index
+   going-further/index
+   processes/index
\ No newline at end of file

developer/introduction.md

-Introduction
-============
-
-Greetings!  In the developer manual of Jami, you will learn about how
-Jami works from the high level, to the low, with some examples.
-
-## Table of contents
-
-1. {doc}`apis-of-jami`
-2. Basic features
-    1. {doc}`account-management`
-    2. {doc}`contact-management`
-    3. {doc}`swarm`
-    3. {doc}`calls`
-    5. {doc}`file-transfer` (deprecated; see {doc}`swarm`)
-    6. {doc}`message-displayed-status`
-
-3. Advanced features
-    1. Manage audio/videos
-    2. Call recording
-    3. [The push notifications system](https://github.com/savoirfairelinux/opendht/wiki/Push-notifications-support)
-    4. What is a DHTProxy
-    5. Supporting SIP
-    6. {doc}`setting-up-your-own-turn-server`
-    8. {doc}`synchronizing-profiles`
-
-4. {doc}`../contribute`
-   1. {doc}`Build instructions <../build/building>`
-   2. {doc}`submitting-your-first-patch`
-   3. {doc}`feature-requests`
-
-5. Group chats in details
-   1. Description
-   2. {doc}`connection-manager`
-   3. DRT
-   4. {doc}`calls-in-swarm`
-
-6. Drafts
-   1. {doc}`conference-protocol`
-   2. {doc}`synchronization-protocol`
-
-## Description
-
-If you are reading this, chances are you'd either like to contribute
-to one of Jami's components/projects, or to implement your own client.
-There are three main layers in this project:
-
-1. [OpenDHT](https://opendht.net), used for the p2p communication.
-   You can interact with this library like any C++ library, or using
-   the Python wrapper, or via its [REST
-   API](https://github.com/savoirfairelinux/opendht/wiki/REST-API).
-
-2. The daemon, which is the main part.  It's the part which does all
-   the logic for Jami and interacts with OpenDHT, pjsip, FFmpeg, and
-   the other libraries, and implements the whole protocol.  If you'd
-   like to do create a new Jami client, we recommend implementing it
-   on top of this daemon, using one of its many APIs (REST, DBus,
-   libwrap, or JNI).
-
-3. The client part, which is basically the *frontend*.
-
-The developer manual of Jami will explain the different features from
-all of these layers.

developer/drt.rst → developer/jami-concepts/drt.rst

@@ -121,7 +121,7 @@ Implementation
 
 When starting Jami, every conversation initiates the creation of its routing table. The initial step is to establish contact with a first node to begin synchronization with other nodes. This process is known as "bootstrapping" and consists of two main parts.
 
-The first part involves retrieving all known devices in a conversation. This is accomplished by checking for known certificates in the repository or verifying the presence of certain members on the DHT (Distributed Hash Table). If a TCP connection already exists with any device in the conversation, it will be utilized. Additionally, known nodes are injected into the routing table.
+The first part involves retrieving all known devices in a conversation. This is accomplished by checking for known certificates in the repository or verifying the presence of certain members on the DHT (Distributed Hash Table). If a TCP connection already exists with any device in the conversation, it will be utilized. Additionally, known nodes are injected into the routing table. If no connection is successful, we will try to find new devices by performing a "GET" request on the DHT to get devices for each member.
 
 The routing table is subsequently updated whenever an event occurs on a node.
 

developer/file-transfer.md → developer/jami-concepts/file-transfer.md

@@ -209,6 +209,5 @@ send a file to B or to C (just have to select the correct conversation).
 
 ### TODO List
 
-1. Add unit-tests (https://gerrit-ring.savoirfairelinux.com/\#/c/9365/)
+1. Use libtorrent?
 2. Show subtransfers status for outgoing files
-3. Offset resume (for failed transfer)