Environnement WAMP pour utilisateur final

Dev
1

Yo! les geeks,

Je développe des applications web standards : Debian + Apache + PHP + MySQL
D’un autre côté, j’ai modifié FireFox 2 en y ajoutant mes propres fonctions Javascript. Exemple : play_sound(“mon_fichier.wav”);
Ca me permet de faire un mix entre appli locale et mode ASP. Joie.

Mais j’adorerais pouvoir faire une appli totalement locale en installant chez l’utilisateur un environnement complet WAMP pré-configuré.
J’ai tout juste commencé à chercher, mais si certains d’entre vous ont déjà testé, ou même connaissent ce genre de solution, je suis preneur.
Attention, important, je précise bien que je vise l’utilisateur final. Je ne cherche pas un framework pour développeur.
Idéalement, ça se présenterait comme un EXE d’installation qu’on aurait configuré. En le lançant, il installe Apache+PHP+MySQL avec les configs qui vont bien. Et fin des opérations.
L’utilisateur ne doit même pas spécialement savoir qu’il a tout ça d’installé. Pour lui c’est une appli comme les autres.

Merciiiiiii
Antoine

2

j’ai oublié le nom, mais il existe un “soft” qui te permet de faire un exe (ou binaire linux) depuis un firefox like et qui permet de browser sur un site web sans pouvoir en sortir.
ça pourrait être une piste.
des que je retrouve le nom j’édite, mais je pense que des gens ici le suggèreront avant.

Bon courage !

3

Connais-tu ZMWS ? D’après la présentation, ça fonctionne sans installation. Ça peut être plus facile à mettre en place.

fser : tu penses à Prism ?

4

Mais mais… desole hein, mais c’est horriblement degueulasse comme concept et comme idee. J’ose esperer que ca existe pas, malheureusement c’est comme le pr0n ca, si tu y a pense, quelqu’un l’a fait :slight_smile:

5

Ah ouais, donc ça voudrait dire que… naaaan, ce serait trop dégueulasse.

[spoiler]

/me cherche sur Google…

6

Salut,

Il y a wampserver (http://www.wampserver.com/) qui fait ce que tu cherches. Quasiment aucune intervention de l’utilisateur si tout se passe bien.

Après t’installe un serveur web, une système de gestion de base de données et un interpréteur PHP qui doivent cohabiter ensemble quel que soit la configuration. Tu te doutes que tout ne se passe pas toujours sans accrocs :

  • Problème de ports 80 occupé
  • Problème d’accès aux fichiers
  • Config PHP de base qui ne convient pas

L’autre solution, c’est de faire une install locale de tous les composants sur ta machine. Tu fais ta config idéale, tu zip le tout. Tu créé un batch qui dézip, installe les services appropriés et les lance, voire déploie ton application et t’as ton installeur. Apache, PHP, Mysql c’est juste des fichiers à déposer dans un répertoire hein, toute la config est stockée dans des fichiers textes et aucun besoin de dll windows. J’utilisais cette méthode à mes débuts pour déployer rapidement mon environnement de travail sur une nouvelle station. :slight_smile:

7

Arf ! (plied) Ni plus ni moins dégueulasse que tout ce qui a été fait jusqu’ici.
Ca me fait doucement rigoler. Du haut de mes 34 ans, dont 25 de code, dont 17 en professionnel j’ai vu passer tous les débats possibles et imaginables sur ce qui était « propre » ou « sale ». Avec des arguments qui allaient du solide au totalement prosélyte. Tiens, juste pour les « vieux » comme moi, souvenez vous de cette bataille qui faisait rage à l’époque des démos entre ceux qui faisaient tout en full ASM et ceux qui mixait du C, voire (ô sacrilège !) du C++… Mon dieu… Nous étions jeunes et cons :slight_smile:

Bref, tout ça pour dire qu’il n’y a aucune vérité.
Une solution qui installe un environnement d’exécution complet ça n’a rien de nouveau, et le fait que ce soit un environnement web customisé ne change rien à l’affaire.

Maintenant, pour avoir un peu approfondi, effectivement la solution de Molokai me semble la plus adaptée : je fais tout moi-même à la main. Parce que finalement, nos amis Apache, MySQL et PHP ont le bon goût d’être très autonomes par rapport au système et de simples copies associées à quelques commandes feront l’affaire.

Antoine

8

Bah desole hein, mais aller installer deux serveurs, ouvrirs des ports dans tous les sens, exposer un utilisateur a des vulnerabilites qu’il sait meme qu’il va devoir gerer et sans realiser qu’il a pris deux dependances enormes sur son systeme qui vont largement depasser les frontieres de ton app en etant dans le systeme (apres avoir installe deux serveurs qui ne vont servir absoluement a rien d’autre que supporter une seule application et un seul client) c’est utiliser une tronconneuse comme tournevis. Meme en essayant de sauver les meubles en demarrant/limitant/tout comme “il faut”, ca depasse largement les consideration d’esthetes du propre et du sale. Alors bon un truc comme ca pour depanner parcequ’il faut aller supra vite ou chai pas quoi a l’arrache en ayant bien conscience de l’horreur de ce qu’on fait… pourquoi pas hein. Chui le premier a faire des trucs crade des fois, et ca a rien de personel, mais ce truc la ca me fait dresser les poils dans le dos.

Ces technologies serveur n’ont jamais ete developpees pour etre utilisee du cote client. Je suis desole si je vois pas le rapport avec l’age du Capitaine. C’est pas un concours de celui qu’a la plus grosse, si tu vas par la ca en fait 10 que je fais du serveur side mais aussi du devel client en pro sur des apps/plateformes utilisees par des dizaines de millions de personnes. Ca fait avancer quoi dans le schmilblick? J’ai jamais dit que tu voulais faire ca parceque t’etais un bouffon du code :). Ca a rien a voir. Je vois pas non plus le rapport avec les debats de langage. Moi je pense que c’est dangereux en plus d’etre inutile, pas fait pour, pas pratique a mettre en oeuvre, impossible a securiser, bancal au niveau architectural et peu fiable. Sans compter l’horreur a maintenir.

C’est pas comme sil y a avait pas moultes framework de UI, des tonnes de DB redistribuables faites expres pour ce genre de scenarios et tout ce qui va avec pour les faire se parler entre eux. Et meme, si tu tiens absoluement a utiliser des concepts web pur sur le client, a faire du cross platform sans se fouler ou autre dans ce genre regarde du cote de Adobe Air, au moins c’est fondamentalement pensé pour.

9

/me se cache les yeux

Moe > oui je pensais à prism ! merci.

Pour revenir au sujet, je trouve ça aussi dégueu, même si on pourrait faire en sorte de n’écouter qu’en local etc … cela dit, je réponds à la question posée, enfin un peu (le déploiement autonome me semblait évident).
l’avantage de prism c’est que tu peux garder ton appli web comme telle, mais la déployer sur un serveur, auquel le « client » accedera via prism, et ça reste « propre » (oui apres là ça devient discutable de faire un « programme pour voir un site » gnagnagana, mais malheuresement, je pense que ça va se développer :crying:)

10

Pas le temps, pas envie, pas l’énergie pour un débat. J’ai passé l’âge et une gamelle à remplir. :slight_smile:
Merci néanmoins !

Antoine

11

C’est pas vraiment une considération morale là. En soit, installer Apache, Mysql et PHP ça va pas faire grand chose à part bouffer un peu de place sur le disque et les disques aujourd’hui c’est pas vraiment un soucis… Ouverture de port ? Euh ouais… Il va recevoir une alerte de son firewall avant et il aura le choix d’accepter ou pas. S’il n’a pas de firewall, bah euh, le port était pas fermé, ça va pas lui changer la vie. Au développeur de configurer Apache pour pas accepter de connexion externes (et c’est le cas sur Wamp, tout comme MySQL, utilisation locale seulement). Bref, on déstabilise pas le système, on ouvre pas de faille (sauf les failles potentiels liées aux logiciels mais le mec qui développe en .NET est confronté au même problème, il peut pas gérer les failles du framework).

Après oui on est clairement dans le concept « chasse aux mouches avec un bazooka », mais bon l’utilisateur a la liberté de considérer que l’application est trop lourde pour son utilisation et la virer. S’il n’a pas la capacité de s’en rendre compte, est-ce que le débat a vraiment lieu d’être ? Il va trouver une application qui répond à un besoin, et ce type d’utilisateur se contrefout de savoir quel est le procédé utilisé (pour peu qu’il ai la capacité de le comprendre, sans être péjoratif, chacun ses priorités).

Ces technologies serveurs ont été conçus pour être utilisées de manières distribuées. Rien à voir avec une question d’IP, de localisation de machine, etc. Chaque process prend en charge une partie du boulot :

  • MySQL la gestion de données (peut-être s’orienter du côté de SQlite dans ce cas de figure, il a été prévu pour ce genre de situation).
  • Apache le service de livraison
  • PHP la logique applicative

Que ce soit regroupée en local ne pose, en soit, aucun problème. C’est juste de la perte de ressources matérielles inutile. L’avantage de la solution ci-dessus c’est que le jour où on veut passer en multi-utilisateur :

  1. On déstabilise pas l’utilisateur, pour lui rien ne change
  2. On a juste à configurer deux trois options dans les serveurs

Alors que partir sur une application lourde et passer en multi-utilisateurs par la suite, bonjour les emmerdes.

Bref… Je suis pas partisan de cette solution, sauf en utilisation personnelle, mais je vois pas en quoi elle provoque des hauts-le-coeur. :slight_smile:

12

Houlà, que je suis pas d’accord !

On a tout ce qu’il faut comme outils / frameworks / technos pour nous permettre de concevoir des applications modulaires dont les composants communiquent soit directement, soit via WebServices (ou autre). Je pense notament à WCF qui permet d’adresser ce genre de scénarios facilement pour le monde .Net par exemple. On définit des interfaces, on les implémentent, on crée une petite classe Factory qui va bien pour au choix instancier en mémoire le service, ou bien fournir un proxy vers un service distant. Ca marche très bien, et c’est en production chez mon client actuel notament.

Au passage, je plussoie, WAMP sur un poste utilisateur final… NON
MySQL, quoi qu’on en dise, ca bouffe des ressources, ca demande un peu d’administration quand même, et ca passe forcément par la couche TCP/IP
Apache, même combat
PHP, c’est quand même fait pour du Client / Serveur en mode Request / Response, pour une application cliente, c’est pas franchement adapté
Tu me diras y’a quand même JavaScript / Ajax pour repasser en mode plus « programmation évènementielle », et là je te dirais : tu sais vraiment pas quoi faire de tes nuit? GTA4 vient de sortir ! ^^

13

Et au passage installer IIS sur une machine client pour faire une appli client, ca serait 100% tout aussi ignoble. Donc non ca a absoluement rien a voir avec la gestion eventuelle de faille d’un framework. C’est quoi le prochain truc? Mettre un sendmail parcequ’on veut envoyer trois emails? On est pas du tout dans le meme univers a installer des serveurs pour soit disant en faire des composants logiciels. C’est absoluement pas fait pour, et l’info c’est pas magique, quand c’est pas fait pour ca marche mal. Il y a des tas de DB qui marchent en mode client, avec des contraintes specifiques pour fonctionner dans ce mode, c’est pas pour faire joli, c’est parceque utiliser un serveur sur le client, c’est ouvrir la porte a des tonnes d’emmerdes. Maintenant si y en a qui veulent faire, tant pis hein, ca va pas m’empecher de dormir :slight_smile: vu que c’est pas moi qui vais maintenir, mais quand ca finira sur le dailywtf c’est ptet moi qui lirait :crying:.

14

Je travaille pas mal en .NET sur une grosse application distribuée (enfin plusieurs, mais c’est pas le débat). Et facilement c’est pas vraiment le terme que j’aurais choisi. :cry: Bon ceci dit on passe pas par WCF qui, tu me corriges si je me trompe, est assez récent non ? (framework 3.0 sauf erreur).

Y a moyen de le faire bien entendu, mais pas au même prix (sueur et temps) qu’avec une petite installation apache+php+mysql. Et surtout, il faut prévoir la logique multi-utilisateurs dès le début (sessions, accès concurents, etc), alors qu’avec la solution évoquée plus haut, elle coule de source. Et c’est pas portable (enfin pas autant que la solution en question).

PHP n’a rien à voir avec du client serveur au passage. C’est un bête interpréteur, il en a rien à faire de savoir que la requête provient de X, Y ou Z, c’est le boulot d’apache ça, lui il parse du code et renvoi le résultat de l’exécution, point barre.

Ensuite AJAX n’a rien à voir avec le problème. Le fait d’avoir Apache, PHP et MySQL en local ne rendra pas ton application plus « riche », ça change strictement rien à ce niveau.

Bref faut pas tout mélanger, sinon effectivement ça devient facile de voir le mal et dire « NAN FAUT PAS ». :slight_smile:

@Glop : Ton argument n’a pas de sens. T’es en train d’expliquer que 99% des hébergements mutualisés font n’importe quoi (ils hostent en majorité le trio sur une même machine ou un même cluster). Et les serveurs dédiés de monsieur tout le monde, la même chose. Pour MySQL dans ce cas-là, les requêtes proviennent de localhost (bien souvent même, ils ferment l’accès à MySQL depuis un autre client que localhost). Bref, vos arguments tiennent plus de la superstition qu’autre chose les gars. :crying: Installer AMP sur un poste client pour une utilisation locale n’a rien de pire qu’installer la même chose sur un dédié, je dirais même plus, c’est exactement la même chose ! C’est l’utilisation finale qui diffère et là oui, dans le cas du poste client qui hoste tout, y a un léger abus de consommation de ressource par rapport à l’utilité (encore que c’est subjectif). Mais l’argument « c’est pas prévu pour » n’a pas de sens.

[ol]
[li]D’un point de vue technique, ils sont prévus pour fonctionner dans des processus différents, ce qu’ils font qu’ils soient installés sur une même machine ou sur différentes machines (y a même moyen de faire abstraction de la couche TCP pour faire communiquer PHP et MySQL).[/li][li]D’un point de vue moral, ils sont prévus pour répondre à un besoin, ce qu’ils font qu’ils soient tous sur la même machine ou pas. Suffit de tuner Apache et MySQL pour réduire leur consommation étant donné qu’il n’y a qu’un utilisateur de prévu.[/li][/ol]
Après une installation Desktop pour une utilisation multi-utilisateurs, là oui faut se gaffer. Car là on ouvre le serveur sur l’extérieur et c’est le début des emmerdes (encore que pour une utilisation en réseau locale ça pose pas de problème mais faut configurer un peu).

15

Non ca n’a rien a voir.

Non ca n’a rien a voir.

Non ca n’a rien a voir. :slight_smile: Installer un serveur quand tu veux installer un serveur, pour servir des trucs dans le role qui est donne a un serveur (multi client, multi utilisateurs, etc), oui evidemment. Installer un serveur sur un poste client dans le seul but de faciliter le fonctionnement interne de ton app quand une seule connection sera jamais faite entre le client et le serveur, ca se taper tous les problemes d’un serveur pour aucun des benefices. Et oui, c’est pas prevu pour du tout. Meme les serveurs qui sont prevu pour faire exactement ce que tu decris en gestion de communication cross process, en monoposte ou en multiposte (On peut penser a COM/DCOM ou OLE), sont carrement pas architecture de la meme maniere qu’une apache ou qu’un IIS. Je veux bien qu’en surface c’est tout pareil c’est « des process qui se parlent » mais si ca tenait qu’a ca on aurait pas besoin de centaines de protocoles et d’architecture pour repondre a des besoins tres tres differents… Au final c’est du code partout, ca se parle par des API, c’est tout pareil. Oui super.

Ca me fait un peu sourire parceque c’est ultra symptomatique d’un truc qui est en train de se passer un peu partout depuis quelques annees: le developpeur web/serveur qui (re)decouvre le developpement d’application client et qui croit qu’il fait toujours le meme boulot. Bah desole mais non :crying:. Depuis deux, trois ans on est en train de redecouvrir les joies de la richesse d’un client intelligent qui sait faire plus que de l’affichage, que ca soit sur le web, ou sur le concept Apps+Service a la iTune et autres, c’est clairement l’evolution. Mais le soucis c’est qu’a bien connaitre un marteau, alors quand y a des trucs qui ressemblent vaguement a des clous partout ailleurs, on y va joyeusement avec le truc bien familier. C’est exactement ce que tente d’exploiter Adobe Air par exemple, ou Silverlight dans l’autre sens d’ailleurs. Alors oui il y a plein de bonnes choses dans le devel web qui sont applicables du cote client, (et vice-versa) et les evolution des framework des 10 dernieres annees font que ca de rapprocher les deux, mais y a pas que le client/serveur facon web dans la vie :cry: et tout n’est pas « fait pareil » ailleurs, pour des bonnes raisons! Ca fait un peu des dizaines d’annees avant le web qu’on fait du « rich client », et on a pas attendu apache pour en faire. A vouloir calquer des architecture inadaptees sur des problematiques differentes alors qu’il existe des solutions bien maitrisees on rend service a personne, on augmente les surface d’attaques sans raison, on se cree des dependences ingerables, difficiles a maintenir dont les traces (footprint) depassent de partout en dehors de l’applicatif sans raison. C’est dangereux, ca marche mal et ca n’a d’interet que de pas avoir a apprendre les concepts lies aux applis client (ce qui encore une fois si on doit privilegier la vitesse par dessus tout peut etre une argument valable, mais pas au point d’en faire un quelquechose de parfaitement normal en general).

16

Donc on est bien d’accord sur le fait que c’est pas « idéal » mais qu’il y a pas de quoi hurler au feu non plus. :slight_smile: J’ai jamais prétendu que c’était mieux, juste que c’était faisable, que c’est pas une aberration complète comme les premières réponses semblaient le dire et que ça n’ouvraient pas de faille supplémentaire si c’était un minimum maîtrisé. :crying:

Pour les « ca n’a rien à voir », je dois dire que tu éludes un peu rapidement par contre. :cry: Ca a tout à voir, dans ces configs, Apache, PHP et MySQL communiquent en local exactement comme la solution proposée, y a que le client qui change. Mais au final, le client qu’il appelle le serveur via un IP distante ou le localhost, Apache fait la même chose. Le bénéfice étant que le jour où l’application passe en mode distribuée (sur différentes machines et non plus sur différents process), il a rien à changer au niveau de l’applicatif (et ça c’est autrement plus dangereux niveau source de failles, que de simplement reconfigurer le serveur. J’ai tendance à penser qu’il y a plus de chances de générer des bugs / failles en modifiant les sources mon applicatif métier, pour une modification de cette envergure s’entend, qu’en reconfigurant mon applicatif technique).

Donc non effectivement c’est pas la meilleure solution, mais oui c’est tout à fait faisable et pas mortel. :stuck_out_tongue:

17

Tout petit passage hors sujet sur WCF, oui, c’est Framework 3.0, et dans ce cas précis, on peut même s’en passer et faire du Remoting old school, ca marche aussi (bien sur, on perd le côté WS-*, transactions et compagnie, mais on peut faire avec).

A propos de PHP, oui, c’est bete moteur de script qui peut être utilisé pour autre chose que générer du html / xml / txt / jpg, mais au final, quand tu le host dans Apache, et que tu le consomme avec un browser Firefox (comme c’est censé être le cas ici), euh… bah tu te cantonnes à générer du x(h)tml / css / javascript, voir un peu de jpg, et si tu es vraiment poilu du XUL, et tu fonctionnes en mode client / serveur, avec tout ce que ca a de chiant, et de pas du tout adapté à faire du “smart client”.

Si les compétences d’Antoine sont plutôt tournées vers le WEB, partir sur du Adobe Air, me parait effectivement vachement plus adapté (au passage… a quand un équivalent les Widgets Silverlight, sans avoir besoin de Moonlight / mono sur sa machine? :))

18

Ouaip mais si tu fais du remoting old-school, bah… t’es dans une configuration client serveur. Donc je vois pas la différence avec Apache pour le coup ? :slight_smile: Du moment que tu dois prévoir une solution multi-utilisateurs, t’es obligé de passer en client serveur d’une manière ou d’une autre.

Donc, le vrai débat c’est : y a-t-il la moindre chance qu’un jour cet application partent en multi-utilisateurs. Si oui, alors faut envisager une solution client-serveur dès la conception, et là le trio Apache+Php+MySQL ou le .Net Remoting, c’est affaire de goût (encore que, avec le remoting, tu te tapes la conception du serveur avec tout ce que ça implique, ce qui n’est pas le cas avec Apache and Co). Si non, alors effectivement resté en client lourd.

19

WTF, j’ai l’impression qu’on ne parle pas de la même chose… Au passage, .Net Remoting, ce n’est pas forcément Client Serveur, ca peut être Peer to Peer, et tu peux avoir la même notion de contrat / factory qu’avec WCF, et hoster tes composants directement en mémoire, ou de manière distribuée, à la demande.

Le but du remoting est justement de ne pas avoir à définir de protocole de communication entre ton consomateur et ton composant. Tu utilises ton composant comme tu utiliserais n’importe quel objet « local ».

Et au passage, pour répondre au « vrai débat », Adobe Air, adresse très bien ce scénario aussi.

20

Un serveur qui peut servir des donnés à pleins d’utilisateurs en meme temps peut très bien le faire à un seul, ca pose aucun problème et c’est tout à fait prevu pour le permettre. Se taper tous les problèmes d’un serveur pour aucun des benefices ? Je vois pas quels sont ces problèmes, si la config est bien faite, ca ne pose pas de problème, en dehors des quelques ressources supplementaires consommées, ce qui est dans beaucoup de cas negligeable. Mais sinon, ca a un gros avantage, celui de ne pas developper 2 fois l’application si celle ci doit pouvoir s’utiliser à egalement distance. Autre avantage, c’est portable: si on veut faire tourner l’application sur une machine sous Linux, il n’y a que quelques modifications minimes à faire.