Reprise du message précédent :
J'ai pas suivit tout les details, mais y'a aussi la solution flash uploader aussi, avec l'avantage de pouvoir faire de la multisélection de fichier. ( Et l'inconvénient de se vautrer sous linux )
( Je parle d'utiliser la feature du flash en faceless, l'ui on peut continuer à la faire html/css classique par dessus avec le bridge flash<->js )

C'est pas con, par contre l'event onProgress, qui est envoyé à chaque changement d'état, mais de manière periodique, donc niveau fluidité ça change rien. Par contre niveau controle d'état ça roske bien.  

 
L'avantage aussi c'est que c'est flash directement qui check l'avancement, t'as pas besoin d'avoir un canal de discussion/pooling supplémentaire qui vient pomper des ressources serveur.

Prototype 1.6 released
script.aculo.us 1.8 released
 
C'est parti pour les tests

Non  

La révolution c'est le Putsh

Putain, c'est saiske!

http://www.thecodingmachine.com/op [...] tation.avi

Disclaimer :

+

si c'est pas un français ça

ed : ah bah barbecued

YOUR EYES WILL BLEED

le php à son sommet: http://forum.hardware.fr/hfr/Progr [...] 9444_1.htm

Bon en gros, Xaja c'est basé sur les sockets en php :

http://fr3.php.net/manual/en/ref.sockets.php

Plus de la sérialisation, je m'interesserais bien mais Php c'est contre ma religion

Tiens, j'aimerais bien savoir si vous feriez ça comme moi.
 
Application : Génération de trombinoscopes à-partir de divers critères.
 
Problème : les photos sont dans un blob dans la base. Et je ne veux pas aller me connecter à la base une fois par photo.
 
Ma solution simple : on récupère tout dans le script qui génère la page contenant les photos, et on met les données en session. De plus, on utilise un cache sur le disque pour les photos.
 
La question que je me pose : vous voyez un moyen de ne pas se retrouver avec des sessions d'une taille pas possible si on a une population de plusieurs centaines de personnes?

je mettria pas les images en session , il y a le cache du navigateur pour ca

Qu'entends-tu par "on met les données en session", quelles données ?
Le cache sur le disque c'est suffisant à mon avis.
Au pire tu peux déclencher la génération du cache en "préventif".

Quelles données ? Les images ? Tu fouts quand même pas une centaine de photos en cache quand même ? (je suppose que non, et je suppose donc que je n'ai pas compris ce que tu veux dire )

Edit : BBQed

Bon, j'imagine que c'est pas très clair, vues les réponses.

Mettons que j'ai une page trombino.php qui est censée afficher un un paquet de photos. Cette page connait la liste des gens à afficher.
Elle va donc retourner du contenu html avec dedans tout un tas de
<img src="affichemaphoto.php?id=xxx" >

Je ne veux pas que chaque appel à affichemaphoto.php génère un accès à la base. Donc j'envisage dans trombino.php avant d'envoyer le html de coller les photos en session, et de les reprendre dans la session à chaque appel de affichemaphoto.php.

Mais au-secours la taille de la session.

Donc le cache du navigateur n'a rien à voir là-dedans. Par contre remplir le cache en préventif c'est une bien meilleure idée que la session...faut juste que je regarde comment faire ça avec smarty.

[edit]...avec un bête fetch sans utilisez la valeur de retour...

Ce n'est pas possible de créer les images sur le disque ?
 
Voici comment moi je ferais, mais je n'ai pas toutes les infos donc ça peut ne pas convenir au type de projet sur lequel tu es :
 
<img src="/public/pictures/trombi/28.jpg" /> (ou 28 est l'id de l'image)
 
Et un .htaccess dans le dossier trombi avec un truc du genre dedans :
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ([0-9]+)\.jpg$ /tapage.php?gen=$1 [L]
 
Et la page en question génére l'image sur le disque. Donc si l'image existe on l'affiche, et si elle n'existe pas on la créé...
 
Enfin voila l'idée quoi

 
Là tu ne fais que réinventer le système de cache, qui ne pose pas de problème. A la première génération tu auras toujours autant d'accès à la base de données que de photos...ce qui est très lent. Non, la solution de générer le cache "à l'avance" me convient bien.

 
Je vois pas ce que tu veux faire alors ... soit les images sont récupérées de la BDD au fur et à mesure, donc X images = X requêtes, soit tu fais 1 seule requête et t'as pas d'autre choix que de stocker toutes les images en session. Compte tenu de ce que tu veux faire, je vois pas ce qu'il peut y avoir d'autre comme solution en fait.

Faire une seule requête, et au lieu de les stocker en session générer le cache tout de suite (sans rien afficher), puisque je sais que j'en aurai besoin de toute manière...

Et j'imagine que t'as des tranches horaires tranquilles
Donc un script shell + wget sur les urls des images la nuit et hop tu pré-génères l'intégralité de ton cache.

ah non ça par contre ça va pas le faire, je serai surement trop limité en espace disque. Génération à l'appel de la page, cache à durée raisonnable, et vidage de l'ancien de temps en temps.

perso je foutrais les images sur un disque, avec un ID tel que tu puisses avoir facilement le nom de l'image d'après l'id d'un user...et là 0 requetes en bases...
 
parce que ta 3 contraintes qui s'excluent :  
- t'as pas d'espace sur ton disque ==> données en bases
- tu veux pas de grosse requete ==> il te faut un cache temporaire
- cacher tt les photos sera trop gros et pas efficace (si t'as 100 photos, et 10 users simultanés, t'auras 1000 photos en cache, c très nul) ==> il te faut un cache hors session, soit ton disque
 
et tu boucles...

Il est surtout stupide de vouloir mettre les 100 mêmes photos en session pour les 10 users différents. Si t'as un problème de place, tu devrais peut-être générer les photos dans un répertoire temporaire, et placer un script pour supprimer 1/ celles dont le dernier accès remonte à XX minutes 2/ en cas de dépassement de place mémoire allouée à ce cache.

Je suis probablement naïf et stupide, mais un 1To de disque dur, ça coute combien en heures de dev ?

 
J'ai l'impression de me voir moi, il y a 6 mois, quand les ingés de prod ont couiné à propos de nos occupations de filesystem sur les machines de prod

 
...et avoir les images sur un disque c'est pas créer un cache?
Dans ce cas je vois pas pourquoi ce ne serait pas trop gros et pas efficace, comme tu dis...
 
Il n'y aura pas un très grand nombre d'utilisateurs simultanés (normalement). Un cache "à la demande" est la solution la plus adaptée à mon avis, et ta solution est tout simplement soit non réalisable (les photos viennent d'une autre appli), soit revient à créer un cache complet.

ça dépend, tu sais sais combien ça paye les contractuels la fonction publique?

(...et en vrai j'ai simplifié le truc, là, hein...)

Dans l'administration, ils préfèrent les choses simples

En fait, ton seul dilème est de choisir entre une grosse requête + mise en session, et plusieurs petites requêtes ?
T'as comparé les perfs ? ça vaut le coup de mettre 10 Mo de sessions / user ?

 
Non, ya plus de dilemme.
Grosse requête + mise en cache (disque, pas session).

Putain mais je veux bien qu'on fasse gaffe à la sécurité, mais merde, jamais je ne fouterais la conne de "question secrète" dans mes formulaires d'inscriptions

5-6h pour un mec sous payé?

...et beaucoup moins pour moi pour développer un cache.

la diff que je fais entre un cache disque et la mise en session c'est qu'en session tu bouffes de la RAM

Je suis certainement noob, mais je ne comprend rien à cette question
 
Tu programmes les DD toi ?

Il compare le coût de développer une solution intelligente au problème et le coût d'ajouter simplement un disque dur comme un gros bourrin.

 
ouais, en patchant le firmware du DD tu peut biaiser ses politiques pour le write cache et read cache pour rendre ton appli plus performante et résistante à la charge. C'est un peu galère parce qu'il faut faire du dma avec les carte réseau pour pouvoir préfetcher efficacement en sniffant les requètes mais c'est super efficace

TU PEUX PAS PREFETECHER AVEC DU RAID5

T'as combien de photos ? C'est des tofs de type photo d'identité d'étudiants ?
 
Si t'as 100 000 tofs à 50ko la tofs ça te fait 5Go de cache ça va