Re: gérer des fichiers log

In article <sddopq$flh$2@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

On 2021-07-22, Marc SCHAEFER <schaefer@alphanet.ch> 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/