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

[flagos <flagospub@xxxxxxxxx>]

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