evolution.tex

%mainfile: rapport.tex

\section{Évolutions possibles}
\label{section:evolutions}

Dans cette version de \pie, nous nous sommes concentrés sur l'implémentation de notre algorithme et donc sur la spécificité du routage.
Afin de permettre une évolution de l'application, nous avons tenté de respecter au maximum la philosophie \airplug{} dans le nommage des variables et procédures.
D'autre part, chaque fonction est documentée et chaque structure a été pensée modulable afin de ne pas limiter les possibilités de \pie{} à sa version actuelle.

\subsection{Gestion des utilisateurs}
\airplug{} donne la possibilité aux utilisateurs d'une voiture de communiquer grâce à des applications via la borne \wifi. Mais que se passe-t-il si plusieurs personnes dans la voiture décident d'utiliser \airplug{} ?
Dans un tel cas, l'identité de la voiture ne suffit plus, mais il faut identifier chaque personne de la voiture. Pour ce faire, nous avons mis en place la structure d'utilisateurs évoquée précédemment. Dans le contexte de \pie, nous pouvons envisager rapidement de permettre à un utilisateur de récupérer les informations des propriétaires des flux qu'il suit. Ceci pourra être réalisé simplement par l'utilisation de deux nouveaux types de messages : un type pour effectuer la demande d'information, et un autre pour la réponse. Dans le cas d'une demande, nous pouvons imaginer qu'étant donné que chaque n\oe ud peut posséder l'information, il ne sera pas nécessaire que la réponse provienne du propriétaire du flux, mais de toute personne possédant ces données.

\subsection{Connaissance des abonnés}
Dans la version actuelle de \pie, il n'est pas possible pour un utilisateur de connaître l'identité des personnes intéressées par son flux. 
Cependant, cela pourrait être envisagé en ajoutant un type de message spécial demandant à chaque abonné de décliner son identité au propriétaire du flux. 
Il est par ailleurs possible de réaliser une première liste grâce au partage des demandes entre les n\oe uds. Ainsi, en ajoutant une information sur la personne qui demande, nous pourrions croiser nos données en regardant dans notre liste \texttt{forwarded} les n\oe uds qui désirent notre flux. Cette liste ne serait pas complète étant donné que nous n'avons pas forcément reçu la demande de tous les n\oe uds, même éloignés.

\subsection{Des applications tierces}
En ajoutant la gestion des identités, nous pouvons imaginer des applications tierces, utilisant \pie{} comme couche pour l'envoi de messages. Ces applications pourraient entre autres utiliser les destinations des utilisateurs pour proposer divers services comme du guidage, des points de rencontre dans le cas de longs trajets.