Discussion :

[DonQuiche]

@pacs32
Le problème qui va se poser à toi si tu ne passes pas par RDP, c'est que tu vas rencontrer des problèmes de performances pour deux raisons :
* Tu es obligé de renvoyer tout l'écran (ou toute l'application) et non pas seulement les parties qui ont changées. Ou alors de scanner sur le serveur l'image pour détecter les changements.
* Il ne t'es pas possible de savoir quand l'aspect d'une fenêtre a changé, tu dois sonder régulièrement. Donc latence.
VNC utilise des hacks du driver vidéo pour contourner le problème et, malgré ça, les performances sont mitigées.

Pour en revenir à RDP, que veux-tu dire par "c'est juste du bureau à distance" ? RDP te permet de dupliquer l'affichage d'une fenêtre sur un terminal et d'envoyer au serveur depuis le terminal des commandes. Il te permet aussi de recevoir le son du serveur, de rediriger l'impression sur les imprimantes du terminal, de virtualiser le GPU, etc, etc, etc. En revanche, c'est fait pour du 1:1, je ne sais pas si tu peux faire du N:1.

[ctxnop]

@ctxnop
Je ne connais pas assez RDP pour avoir de certitudes mais vu que les "remote apps" s'appuient dessus et qu'elles répondent exactement à ce qui est demandé... Voir par exemple cette vidéo exhibant un WordViewer exécuté sur un terminal depuis un serveur, RDP/RDS semblent bien fournir tout le nécessaire.

Toutefois il se peut que certaines fonctionnalités ne soient dispos que sur les versions les plus récentes de Windows. Peut-être les anciennes versions de RDP (je parle bien du protocole et des API associées, pas des UI fournies avec Windows) étaient-elles sujettes aux limitations que tu décris.

Oui, c'est bien possible que ces limitations existaient à l'époque et plus maintenant, parce que j'y réfléchit, ça doit bien faire 10 ans que je me suis pas intéressé à RDP de près et tout ce que j'en connais dans l'utilisation de nos jour c'est l'ouverture de session.
J'ai regardé les 10 premières secondes de la vidéo sur le viewerword.
En fait c'est exactement comme une ouverture de session classique. Le but est de démarrer l'application du serveur, depuis le client et d'en obtenir l'affichage sur le client. Autrement dit, la fenêtre n'apparait pas dans la session connectée sur le serveur. Ce n'est donc toujours pas la demande d'origine.
Lui il veut se connecter (sans RDP, de manière physique) sur une machine, lancer une application, disons firefox, puis, il se lève de sa chaise, se place devant un autre ordi, se connecte dessus aussi (toujours en physique). Et là, il veut récupérer un affichage de son firefox qui est sur l'autre machine. Le firefox qui est sur l'autre machine doit continuer d'être présent, utilisable, etc... a priori dans la demande d'origine il ne parlait que de pouvoir visualiser la fenêtre, pas la contrôler.

En réalité, la demande d'origine est plutôt la prise de contrôle à distance, à la VNC, mais sur une seule application plutôt que le bureau complet. C'est d'ailleurs peut-être possible avec VNC, encore un truc que je n'ai pas regardé depuis 10 ans

Après, on peux peut-être se poser la question de l'utilité réelle de faire ça ? Suivant le but final il existe peut être une solution beaucoup plus adaptée.

[therwald]

et sa:
http://msdn.microsoft.com/en-us/library/dd162869
http://msdn.microsoft.com/en-us/library/dd145216
ce ne sont pas des moyens ?

Eh non, ce que tu montres ce sont des appels en interne, autrement dit le programme doit être conçu pour dans ce cas. il doit intégrer un serveurqui permet d'établir une connection avec lui. Ou alors il faut utiliser une connection à distance dès le départ en mode remote à la XDCMP ou RDP parce que dans ce cas c'est l'OS quu gère. Faut pas oublier que la plupart des applications sont conçues pour ete utilisées par une personne a la fois...si tu veux une utilisation mobile tu œuvre le plus souvent l'application sur un terminal mobile...