Path: ...!news.misty.com!weretis.net!feeder8.news.weretis.net!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed1-a.proxad.net!nnrp1-1.free.fr!not-for-mail From: Thomas Newsgroups: fr.comp.os.unix Mail-Copies-To: nobody Subject: Re: =?ISO-8859-1?Q?g=E9rer?= des fichiers log References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Sun, 19 Sep 2021 21:11:06 +0200 Message-ID: Lines: 121 Organization: Guest of ProXad - France NNTP-Posting-Date: 19 Sep 2021 21:11:07 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1632078667 news-2.free.fr 4995 91.175.52.121:14435 X-Complaints-To: abuse@proxad.net Bytes: 5721 In article , Marc SCHAEFER wrote: > Thomas wrote: > >> On 2021-07-22, Marc SCHAEFER wrote: > >> > Une application web n'est-elle pas une application graphique? > >> > >> Non, c'est une application client/serveur. Le client (le browser web) > >> peut-être une application graphique (firefox, Chrome) ou pas (links, > >> lynx, w3m). > > > > merci, comme je n'y connais rien en mobile (entre autres) je ne savais > > pas du tout quoi répondre :-) > > J'ai aussi conçu des applications desktop client/serveur. > > D'autant plus que les applications web modernes ne font souvent que > chercher des données en web pour les affichers grâce au javascript > local, ce qui ressemble beaucoup à une application desktop qui se > connecte à une base de données. dis moi si je me trompe : il me semble qu'il reste une /grosse/ différence : - une application desktop est un exécutable compilé pour la plateforme qui l'exécute, - une application web est interprétée par un navigateur. avec des avantages et des inconvénients de chaque coté > > Pour clarifier la discussion, posons: > > - application bureau (desktop) monolithique > > pas d'usage du réseau, d'une base de données réseau, > etc > > - application bureau client/serveur > > utilisation d'une base de données SQL ou autre, y.c. > données sur le web (REST/HTTP) > > - application web classique client/serveur > > présentation par le serveur, mise en forme par le client > (peu/pas de javascript) > > - application web moderne client/serveur > > très similaire à "application bureau client/serveur" > > - application mobile native > > très similaire à "application bureau client/serveur" > > - application mobile Progressive Web App > > très similaire à "application mobile native" sauf que > 100% HTML/CSS/JS pour l'instant, celle que je fais semble être : une "application bureau monolithique" (d'après ta description, parce que d'après ce que dis Stephane c'est pas sur, puisqu'il y a une bibliothèque. je ne saisis pas encore bien toutes les nuances) pour ma part, je me vois faire : - application bureau client/serveur - (peut être) application web classique client/serveur pour l'instant c'est tout, et c'est encore du futur ... > Il ne me semblait pas que le fait que l'application soit bureau ou non > change grand chose: il faut des configs quelque part (locale ou > distante, possible aussi pour une application bureau client/serveur). il me semble qu'il y a des contraintes diverses, non ? par exemple, peut on passer un argument à une application web pour qu'elle lise un fichier de config local ? clairement, les logs sont gérés directement par le serveur, les potentielles mauvaises pratiques n'affectent pas l'usager, à qui on n'a pas besoin de demander d'envoyer ses fichiers de logs pour comprendre le pb. tandis qu'avec une application bureau client/serveur, il y a une part de chaque coté, le serveur ne gère pas tout. > > > c'est pas gênant ? (et STDOUT est fait pour quoi ?) > > Pour une application qui ne communique en fait pas avec l'utilisateur en > console, on peut définir stdout comme les notifications normales et > stderr comme les erreurs. est ce que le debug équivaut à des "notifications normales", ou est ce que c'est autre chose ? > > Pour une application qui communique avec l'utilisateur en console (pas > ton cas me semble-t-il), en fait, le "gros morceau" est une application graphique, mais : - le même exécutable peut aussi être utilisé en CLI à la place - d'autres exécutables, qui servent aux tests, font les 2 en même temps comment me conseilles tu de gérer ça ? > stdin/stdout est pour l'interaction > utilisateur, stderr pour les erreurs. quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive mode permits only one file on the command line", comment les catégorises tu ? interaction utilisateur ou erreurs ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/