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

[flagos <flagospub@xxxxxxxxx>]

ah ben cool pour les sessions !

Le 11 février 2012 15:02, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
> oui ok c'est ce que je me doutais
> en gros on monte deux app sinatra sur un namespace différent.
> et on peut lancér l'autre app via un main si on veux.
>
> le truc pour les session, a priori elle ne seront pas commune, donc pas de
> souci.
>
>
> Le 11 février 2012 14:44, flagos <flagospub@xxxxxxxxx> a écrit :
>
>> ok ;-) Talk in code:
>>
>> En gros, dans webserver, on a:
>> class ThinServer < Thin::Server
>>
>>  def initialize(bind,port)
>>    super(bind,port, :signals => false) do
>>      use Rack::CommonLogger
>>      use Rack::ShowExceptions
>>      map "/" do
>>        run ::WebServer
>>      end
>>    end
>>  end
>>
>> end
>>
>> Ce qui nous interesse, c'est de mutualiser le serveur Thin entre les 2
>> applis. Du coup, on pourrait faire 2 classes et faire
>>
>>      map "/oauth2/" do
>>        run ::oauthWebServer
>>      end
>>      if config["magic_option_pour_enabler_l'appli_cliente_dans_serveur"]
>>        map "/" do
>>           run ::appliWebServer
>>        end
>>      end
>>
>> et fournir un autre main.rb pour lancer l'appli séparement. Et du
>> coup, le fonctionnement 1 serveur ou 2 serveurs devient configurable !
>>
>> Au niveau code, ca nous oblige dans l'appli cliente a passer
>> uniquement par du oauth (comme tu l'as souligné, c'est pas un mal). La
>> seule embrouille que je vois a gérer c'est pour les sessions, ce
>> serait un peu du bricolage.
>>
>> Le 11 février 2012 13:04, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
>> > hum j'ai pas trop compris ta dernière idée ...
>> >
>> > Le 10 février 2012 15:30, flagos <flagospub@xxxxxxxxx> a écrit :
>> >
>> >> 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
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Tapé depuis mon clavier
>>
>>
>



-- 
Tapé depuis mon clavier