Reprise du message précédent :

tu peux aussi manipuler du XML pour faire des listes dynamiques, sinon, tu peux aussi passer par un proxy ( php , asp ,... ) pour faire ws<->json

 
c'est la meilleure des approches si tu veux faire un truc mainenable

c aussi la meilleur si tu veux pas que ta team te jette des pierres...

Interface utilisateur < - > applicatif intranet < - > WS

Nan justement, c'est typiquement pas l'approche que je veux
C'est un nouveau projet, l'equipe va grossir ( soit pour bosser sur le nouveau, soit pour bosser sur de l'ancien).
Je veux pas que les "limitations" de  de l'équipe actuelle conditionne les choix sur les technos.

edit: Et pour revenir sur le sujet "j'impose la techno" oui c'est vrai.
Mais evidement que avant d'en causer ici, on en a déjà bien parlé en interne et je sais déjà plus ou moins vers quoi on se dirige. Mais ça ne doit pas être une contrainte.

Je crois qu'il y a quiproquo
C'est quoi une liste dynamique pour toi ?
(dans mon esprit, j'étais parti sur des <select> liés donc les valeurs sont récupérées en AJAX, d'où le JSON )

Je partage pas ton point de vue mais celui de Jubi alors

Dites les gens, j'avais une autre méga question : vous connaissez des solutions de backup pro online ? Genre ici on a des données qu'on aimerait backuper ailleurs physiquement mais comme y a pas des masses de moyens non plus, je pensais à de l'hébergement type mutualisé ou dédié. Genre toutes les nuits, le backup se lance et s'uploade sur le site et voilou.
Je me demandais donc si y avait des solutions bien/fiables/pas chères et le cas échéant ce que vous connaissez ou conseilleriez

 
Et surtout, le drop down menu tel qu'il a été inventé à l'origine était tout en haut de l'écran (forcément, apple ... ), ce qui le rendait bcp plus facile à viser, au lieu de chopper un carré au milieu d'une page web, tu bombarde comme un porc vers le haut de l'écran et tu click, pas besoin de viser précisément. Ensuite vu qu'il reste ouvert tant que tu reclick pas, suffit de bouger latéralement pour visiter tout les menu.

 
Gaffes aux mapping automatique xml<->json, c'est trèèès facilement super merdique.

 
j'avais developpé une solution de sauvegarde il y a 2 ans dont c'etait le but
 
mias je te le deconseillerai  

• c'est moi qui l'ai ecris en java qui n'est pas mon langage préféré
• ils n'ont personne  pour le maintenir

Backuppc sur un serveur distant rulez

En pratique tu veux backupper quoi : serveurs, desktop, laptop... ?
Environnement des machines à backupper ?
Backup en pull (la solution de backup vient récupérer les data, backuppc fonctionne comme ça) ou push (les machines déclenchent elles-mêmes leurs backups, + pratique pour les laptop par exemple) ?

Dans un premier temps : serveurs, sous Ouinedoze, y en a pour 30 Go environ (non compressés). Pull ou push, peu importe, je ne pense pas qu'il y ait de préférence. Y a un gros avantage d'une des 2 méthodes par rapport à l'autre ?
 
Pour BackupPC, ça a l'air pas mal mais a priori on ne serait pas maîtres du serveur de backup. Ou alors j'ai mal compris et il faudrait installer le serveur ici qui collecte les données/fait partir les jobs et envoie le tout une fois fini sur un serveur d'hébergement ?

Comment peut-on faire des mesures de perfs quand d'une fois sur l'autre la même page s'affiche entre 5 secondes et 20 secondes ?

Je sais que mon hébergeur a mis "le minimum de BP", mais j'y connais rien, ça vient de là ?

firebug+yslow?

Firebug obligé pour voir les timings
Yslow chépa c'est quoi

Tu sais utiliser l'internet mondial?

http://developer.yahoo.com/yslow/ c'est un outils d'optimisation coté client
 
 j'ai pas encore trop joué avec mais y a quelques trucs interessant

wwwi je crois (croyais)

Enfin bon ça va pas répondre à ma question tout ça

Non pas d'avantage particulier, sauf pour les machines nomades où quand t'es en pull ben tu sais jamais trop quand la machine à backuper va être dispo sur le réseau.
 
Le principe de backuppc c'est que t'as une machine avec backuppc installé dessus et qui va, suivant un planning défini (tu peux faire des super règles de planification), aller backuper les machines que tu lui auras configuré (via rsync, samba...). Ca gère la compression des backups, les backups sont historisés, t'as une interface web pour consulter (et même restaurer) les différentes versions des fichiers.
Donc dans ton optique, tu prends un serveur dédié offsite, tu installes backuppc dessus et il va venir se connecter sur tes machines pour récup les données.
Pour des raisons de sécurité (tu vas pas forcément laisser toutes les machines de ton parc dispo de l'extérieur ), tu peux prévoir 2 serveurs. 1 offsite avec backuppe qui va se connecter sur un second serveur en interne situé dans une DMZ qui lui va s'occuper d'agréger les data à sauvegarder.

Nan mais c'est plus compliqué que ça
Mon WS va me permettre de "jouer" avec mes objects métiers, grosso modo je lui envoie un flux(dont le format reste à définir) contenant la déclaration d'une nouvelle personne. Le WS doit me répondre "Ok personne créé" ou "Pas Ok personne existe déjà" ou "Données de la personne incohérentes avec les règles fonctionnelles".
Le but c'est que le WS soit interrogeable par 3 applis différentes ( appli intra, site inter et edi), mais les parties inter et intra  auront également une partie applicative "à elles".

Et pour reprendre l'exemple de la liste "dynamique", un utilisateur est sur l'écran de recherche d'une personne et valide sa recherche "je cherche une personne née en 1938, brune et gauchère".
L'applicatif intra reçoit les params, construit le flux, l'envoie au WS, récupère la réponse et le remet en forme pour l'envoyer au navigateur.
Si l'appli inter envoie le même flux (qui ne sera peut-être pas construit dans les mêmes circonstances), il se prend la même réponse, mais le traitement  de celle-ci sera différent.

Okai merci bien J'vais regarder d'un peu plus près, donner les infos à mon chef et i verra bien

Ok on est d'accord    
Dans ce cas là pour moi ce serait du SOAP pour les WS.
C'est standard et ça te permet d'ouvrir ton appli à d'autres applicatifs si besoin en ayant rien d'autres à fournir que le WSDL.

la majorité des wsdl que j'ai utilisé etaient a base de java  
 
mais je sais pas si il ya une raison particulière a ca

ben java ça roxxe...
 

Nous ne voyions pas d'autres explications

Moi les fois où j'ai fais du SOAP, le serveur était en .NET et la partie cliente en PHP et ça marchait très bien

Bon !
On a taiche, -- et uriel. D'ici la fin de semaine on aura récupéré Nray
Plus qu'a virer gatsu, florentg et les étrangers divers et avariés

 
 
euuuhhh, c'est quoi un site en construction pour eux ? Parce qu'il marche mon vrac...  
 

trop de liens morts?

 
un en page d'acceuil ... c'est tout ce que j'ai trouvé ....

C'est bien parce que progressivement on arrive là ou je voulais être au début
Sur les deux applicatifs inter/intra, le consensus interne portait plutot sur du PHP.
Pour l'EDI, ça sera vraisembablement en PERL ( c'est des gros fichiers csv qui sont envoyés, on a tout essayé c'est PERL qui cartonne le plus).
Reste le WS, donc je vais over-résumé ma question, WS/SOAP:

• java,  
• .net,  
• php,  
• autre

merci

T'avais qu'à mieux formaliser ton besoin
 
Pour l'EDI t'as des grosses différences de perfs entre PERL et les autres technos ?
Parce que la maintenance d'un truc en PERL c'est pas le même coût qu'une maintenance PHP par exemple

Nan mais c'est bien justement qu'à partir de la problèmatique éxposée l'archi semble logique.

Oui pour les différences. Et pour la maintenance:

• on a(est vu que j'en fait parti) plusieurs dans l'equipe à être fluent en perl.
• le prog est relativement simple, lecture du gros fichier, éclatement en plusieurs flux xml. S'tout

 
sauf erreurs, tous le permettent, tous ont des lib dédiées donc ca revient vraiment à :
- qu'est-ce que tes gars savent coder
- qu'est-ce qu'ils veulent coder
- qu'est-ce que tu sais maintenir derrière, sachant qu'il faut penser un poil plus large (I&O : gestion des serveurs, est-ce que c une techno déjà hébergée dans ta boite, est-ce que t'as des admins qui suivent, est-ce que t'as des préconisations de ta boite, etc...)
 
ce qui est plus ou moins ce qu'on a déjà dit

A part que je sais pas si y a un driver de dispo pour ta base de données, mais t'as jeté un coup d'oeil à Rails ?
Ca fait tout ça très bien ( même si j'ai pas vraiment approfondi les WS )

nan mais j'ai bien compris ton propos
Mais bon, personne n'a jamais fait un WS/SOAP ici? ce que je cherchais eventuellement c'était un retour d'exp sur la techno utilisé ce genre de chose.
La belle théorie du monde parfait c'est bien gentil, mais ça fait pas avancer mon schimilibilik.

Euh très bien, très bien, faut le dire très vite
Webrick est pas crédible un instant en temps que serveur de production et je n'arrive pas à trouver d'infos sur les perfs de mongrel ou de modruby comme WS.
Mais j'aime bien ruby (un peu moins Rails mais bon...) et c'est une solution qui reste envisagée pour les clients du WS ( appli inter/intra en lieu et place de php).

Essaye de voir les perfs avec Lighty, Webrick c'est pas le mieux qui existe.

C'est même le pire qui existe, c'est juste un serveur de dev webrick hein

C'est sur que c'est une solution, programmer un WS avec tous les langages et sur tous les serveurs, faire des tests de charge et prendre le meilleur...
Mais si quelqu'un d'ici l'avait déjà fait sur l'un ou l'autre, je me disais que je pourrais avoir un premier retour.
Bon a priori, c'est pas le cas et on va se demerder tout seul

Comme l'ont souligné Masklinn et Shinuza, Webrick est un serveur de dev uniquement ( et encore, même en dev il tant de plus en plus à être remplaçé par Mongrel ). Maintenant j'utilise pour un site Light + FCGI, bin c'est trivial à mettre en place ( pourtant c'était mon premier deploiement ) et les perfs sont à des années lumières de Webrick.
 
Si t'as le choix entre Ruby et PHP ( et que par exemple y a pas de pb de librairies qui n'existe pas sous Ruby etc... ), je comprend plus qu'on puisse choisir PHP

faudrai vraiment que je teste ruby  
 
mais bon, on est dans une phase d'homogénéisation du SI  ,ca va pas le faire si je pose un nouvel ovni ( l'objectif etant de foutre a la porte windev/webdev et tout ce qui a besoin de citrix )

Pour toutes les bonnes raisons énoncées par jubijub et ratibus, plus sur le fait que je n'arrive pas à avoir de vrais retours d'expérience sur un WS en ruby.
Dis autrement, serais-tu prêt à parier 1M€ que l'équipe(complétée ou pas avec des experts ruby) arrivera à faire un truc qui supportent les contraintes du client en utilisant ruby...
Perso j'en sais rien et c'est bien pour ça que je cherche des infos pour justifier nos choix .