Re: [openplacos-dev] 1,2,3 serveurs web

[flagos <flagospub@xxxxxxxxx>]

yop

Bon je pertinente globalement ce qui a été dit. Je partage vraiment ce
sentiment, j''aimerai pouvoir déporter le webserver comme les autres
clients, qu'il ne soit pas privilégié par rapport aux autres en termes
d'accès aux données ou quoi. C'est d'ailleurs un des objectifs de
oauth2... qui nous amene finalement a se demander s'il vaut mieux pas
merger ce client en terme de simplicité ! C'est con mais ca tourne un
peu en rond lol ...

Une idée pourrie comme ca, qui m'est venue en tapant ce mail: est ce
qu'on pourrait pas faire en sorte que la partie cliente du webserver
soit lancée soit dans le server, soit a part (mais qu'on ait un main
dédié a ce webserver). Ce serait juste un petit include a faire au bon
endroit, et si le client repose entierement sur oauth2 pour les appels
au webserver, ca peut bien se passer non ? Peut etre un peu chaud a
gerer au niveau ses sessions non ?

Le 10 février 2012 12:23, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
> Yop
> pas eu le temps de répondre, semaine assez chargée.
>
> j'avoue que je n'ai pas encore d'avis tranché sur la question.
>
> pour l'appli de config (si elle voie le jour un jour), je dirais c'est pas
> tres genant, et comme tu dis on peut pas trop y couper.
> d'un point de vue user/administrateur opos, ca pose pas spécialement de
> probleme, c'est juste un truc qui sera lancé une fois de temps en temps, qui
> n'a pas vraiment besoin d'etre accessible depuis l'exterieur (en dehors du
> reseau local).
>
> pour le reste, c'est un peut plus compliqué.
>
> merger les deux serveurs a plusieurs avantages :
>
> - on a un opos qui marche out-of-the-box, a partir du moment ou le
> core-server est lancé, on a un "client" qui est fonctionnel.
> - ca simplifie le setup (un seul port a router, ssl pour les deux ...)
> - plus leger, on duplique pas les server et donc la ram.
> - peut etre plus simple d'un point de vue utilisateur, qui ne dispose que
> d'un seul point d'acces web a opos.
>
> pour les désavantages, je dirais :
>
> - comme tu l'a mentionné, pas de possibilité de déporter le truc. je ne
> pense pas que ce soit dénué d'interet, par exemple on peut avoir un
> core-server sur un rasberry pi et vouloir servir le client web sur sont
> server principal (par exemple si on a deja une config apache qui tourne,
> peut etre plus simple a gere pour les nom de domaine etc). apres c'est un
> usecase pas forcement tres courant.
> - attention au melange des genre, on integre un client au server, et il
> faudra faire gaffe de pas integrer des fonctionnalités qui ne seront pas
> accessible via l'api. dans l'idée c'est juste une question de discipline
> mais voila. Ca pose également un problème pour nous au niveau code, a savoir
> que si on ne passe pas par oauth, on risque de devoir gerer deux méthode
> d'identification. ce n'est pas du tout insurmontable mais je trouve ca moins
> propre.
> - niveau contribution et gestio des bugs, c'est peut etre un peu moins
> flexible.
> - il faut voir aussi si ca implique des probleme niveau disponibilité du
> server et ou stabilité du server. a priori non mais c'est une question a
> soulever.
>
> j'ai pas grand chose d'autre qui me viens a l'esprit, a savoir que aucun des
> désavantages n'est rédibitoire.
> personnelement, je n'arrive pas a determiner de quel coté je penche.
> pour moi, 2 server (1 oauth et un client) je trouve ca plus propre, par
> contre ca devient une usine a gaz pour la mise en place.
>
> Le 7 février 2012 22:15, flagos <flagospub@xxxxxxxxx> a écrit :
>
>> Yop,
>>
>> Je relance la discussion pour savoir sur combien de serveurs on part,
>> et corollaire, si le serveur web applicatif est integre au serveur,
>> est ce que les api sont présentées de la meme maniere que sur le
>> serveur oauth.
>>
>> Contexte: On avait 2 serveurs web jusque la: 1 en rails pour l'appli,
>> 1 autre pour cracher la config. Depuis, on a ajouté oauth. oauth
>> necessite que le core-serveur (qui fera l'authentification) ait lui
>> meme un serveur web. Ca nous ferait donc 3 serveurs web.
>>
>> Le serveur web de config sera lancé avec des droits admin (du moins la
>> config qui sera craché sera calé en root-space). Je pense pas qu'il y
>> ait d'interet a essayer de l'itegrer autrement, on s'en sert une fois
>> pour la config et basta.
>>
>> La question est plutot de savoir ce qu'on fait a propos des 2 autres
>> serveurs.
>>
>> L'avantage de la situation plus ou moins actuelle est qu'on est super
>> modulaire: on peut par exemple deporter le serveur web vers une autre
>> machine, voir meme en hoster un sur une machine a la con au perou (ou
>> plus pprobablement sur une dedibox mutualisée ;-) ) et ne hoster qu'un
>> serveur web minimal en terme de ressources sur la machine qui gere
>> opos.
>>
>> Le souci, c'est que sur une config classique (= appli web hosté sur la
>> machine opos), cela ajoute un poil de complexité pour l'utilisateur et
>> nous ajoute un surcout en ram (20mo a la louche carrée), chose qui
>> coutait moins cher lorsqu'on etait sur dbus..
>>
>>  Ca tire egalement d'autres questions: l'appli utilisera t elle oauth2
>> comme si elle etait un client  meme si elle est integree au
>> core-server ? Le cas ou on souhaite decentrer l'appli sur une autre
>> machine est il realiste ou juste une lubie ?
>>
>>
>>
>> --
>> Tapé depuis mon clavier
>>
>>
>



-- 
Tapé depuis mon clavier