Les coroutines c'est bien, mais c'est pas la panacée

Typiquement, les coroutines (et le async/await en général) résolvent un problème que l'on aurait jamais eu si on avait pris le bon design dès le départ.

Le problème initial, c'est de vouloir faire un code avec des callbacks, parce que, asynchrone tout ça... Et de réfléchir à chaque ressource comme si on devait y accéder avec un chemin complet: "s'authentifier, demander X, puis Y, enfin Z".

Du coup, on trouve du bon vieux QNetworkReply avec ses callbacks/signaux Qt imbitables.

En réalité, le fonctionnement de ce type d'API (authentication/authorization/actions) est typiquement une machine à état. Ton client doit prouver un état (il est authentifié, et autorisé à accéder à une ressource) mais après les requêtes sont assez simple en 1:1.

Dans l'exemple précédent, X, Y c'est juste un état. Une fois demandé, le client est X ou Y, tu peux demander Z directement, voire W si W dépends de X uniquement.

Et donc, typiquement, le bon design, sans forcément faire appel aux coroutines, c'est de maintenir une variable d'état et une boucle principale qui agit sur cet état. En pseudo code c'est aussi simple que:

struct Client
{
 enum State 
 {
 NoConnected = 0, 
 Authenticated,
 Authorized,
 Ready,
 Requesting,
 [...] 
 } state;
 enum ResourceType
 {
 Me,
 KVMList,
 [...]
 } requiredResource;
 [...]
 std::unordered_map<ResourceType, std::function<...> actions;
 void setAction(RessourceType type, std::function<...> func) { actions[type] = func; }
 string answer; // Where all request answer goes
 // OVH API helpers here
 string me() { setAction(Me, [jsonData] { return jsonData["me"]; }); return triggerAction(Me); } 
 string triggerAction(ResourceType type) 
 {
 if (state < Ready) {
 // Handle state ramp up
 waitMainLoopRampup();
 }
 requiredResource = type;
 state = Requesting;
 waitMainLoop();
 state = Ready;
 return answer;
 }
};
std::unordered_map<Client::ResourceType, const char*> ovhAPI = { 
{Client::Me, "/me/"}, 
{Client::KVMList, "/kvmlist/"}, 
[...]
};
QNetworkReply nam;
bool mainLoop()
{
 QUrl url;
 switch (client.state) {
 case NoConnected: url = "http://ovhapi/authentification"; break;
 case Authenticated: url = "http://ovhapi/authorization" + ovhAPI[client.requiredResource]; break; 
 case Ready: return true; // Nothing to do
 default: return false;
 }
 // The only network request element
 nam.get(url).connect(client.actions[client.requiredResource]);
}

Ici, tout est replié sur un seul niveau d'asynchronisme, et plus des asynchronismes imbriqués. Tu enregistres la fonction que tu veux voir exécutée dans le client, et lorsque tu déclenche l'action d'accéder à la ressource, le client te retourne le résultat, de manière asynchrone, sans que tu n'aies à implémenter toute la logique d'accès à chaque objet qui t'intéresse.

Le mainLoop ci-dessus, c'est en gros le scheduler caché dans les coroutines, sauf que c'est un code qui ne cache rien du coup sans utiliser les trucs comme la sauvegarde de la pile et les pseudo tâches.

Surtout, tu peux exécuter des requêtes en parallèle (tu peux avoir plusieurs threads qui gèrent un mainLoop avec le client partagé), ce qui est très difficile à faire correctement avec les coroutines, car justement lorsqu'une coroutine est en "await", elle est ininterruptible (vu que techniquement, elle n'existe même plus sur la pile d'appel).