Ajax upload (progress)

*bump*

-- det kan da ikke passe der ikke er nogen der kan hjælp.

<ole>

I PHP har der efterhånden i mange år eksisteret en kombination af et PHP-upload-script og et Perl-script, der snusede på 'raw post data' - og hvormange bytes, der til enhver tid ligger her. Perl/CGI scriptet kaldte man så hvert sekund i en iframe, hvor også progressbaren lå.
Præcis samme fremgangsmåde bruges idag - blot med Ajax i stedet for en iframe.

Man kan så spørge, om det er hensigtsmæssigt at kalde serveren én eller flere gange hvert sekund - bare for at vise upload-status. Billeder, der skal på WWW, vejer jo ikke ret meget og er oppe i løbet af ret få sekunder, så måske det er overkill.

At der så er mange steder, hvor man tillader folk at uploade direkte fra et digikamera og få formindsket billedet automatisk på serveren, er en anden ting.
Efter min mening kan man sagtens forlange, at folk selv kan finde ud af at formindske deres billeder, hvis de mener, at resten af verden absolut ikke kan undvære deres frembringelser.
Hvis en guitarist forventer at folk skal bruge tid på at lytte til ham, må han lære at stemme sit instrument og selv skifte strenge ... også i en tid, hvor såkaldt dansende statsministerfruer og kuglestødere har langt større genemslagskraft end professionelle dansere, som faktisk har lært at danse  ;o)

/mvh
</bole>

Og hvordan fungere det så, sådan noget raw post data -snusing? Jeg tror lidt jeg har misforstået hvad du siger. For mig lyder det som om du siger at man med HTML laver en upload dialog og med ajax sendes data så til en php side der uploader filen. Og så var der noget med en xmlHttpRequest der kaldes hvert sekund, men hvor den skal komme ind henne forstår jeg ikke, og hvordan den fungere, ej heller.

Jeg må dog indrømme at du har fat i den rigtige ende, omkring overkill, når de fleste ting der vil blive uploadet er relativt små billeder, men så igen, hvis man har mulighed for at uploade flere billeder i en aktion, så vil hvert billed pludselig blive uploadet med en langsommere hastighed end hvis den var det eneste der sku uploades på det eksagte tidspunkt, og så er det måske ikke helt overkill.

Men så igen; at kalde en fil hvert sekund, i forhold til at have en åbn connection, for at have en form live-action-application, i stil med dekstop apps, er atter igen ajax scripteres svar på sockets o.lign., og uden pis - det sucks.

Nej, AJAX sender ikke data, det henter bare information fra et PHP-script, som tjekker, hvor meget der er uploadet. Og det er dette, som kaldes hvert sekund (eller hvor ofte man nu vil have opdateret sin progressbar).

Well, for at få en live-action-uploader, må det da være ajax der sender dataen afsted til den php fil der skal udføre uploadningen, men det er en anden snak...

Hvordan kan php scriptet have information omkring progress af uploadningen? Er det den fil der indeholder upload-scriptet der bliver kaldt af ajax for at få progress status, eller er det en anden, og hvor får den fil der bliver kaldt af ajax, overhovedet progress status fra?

Jeg kunne forestille mig, at det sker sådan:

- INDEX.PHP har en form.
- Via formen vælger brugeren filen A.TXT.
- Formen submitter data til filen UPLOAD.PHP
- Hvis filen UPLOAD.PHP kan aflæse den fulde størrelse på A.TXT, gemmes denne f.eks. i en session
- Samtidigt med at formen submittes, kaldes en AJAX funktion, f.eks. med parameteren "A.TXT"
- AJAX kalder en fil med navnet "STATUS.PHP", og angiver parameteren "A.TXT"
- Filen STATUS.PHP checker filstørrelsen på "A.TXT"
- STATUS.PHP kan tilgå session og sammenligne MAX-størrende med NUVÆRENDE-størrelse
- STAUTS.PHP sender forskellen i størrelsen tilbage, f.eks. i procent
- AJAX opdaterer en DIV med procenten

..mere eller mindre.. :-)

..stavefejl er gratis.. sig til hvis der er noget der ikke giver mening..

Ah, se det giver jo mening! Havde aldrig tænkt på at samligne størrelse med nuværende størrelse -> det er jo genialt!

Måske er der en nemmere måde at få procenten på, men ellers kan man bruge denne formel:

100 - ( ( (maxstørrelse - nuværendestørrelse) * 100 ) / maxstørrelse)

for at få procent kan du da bare sige ((maxstørrelse * nuværendestørrelse) / 100)

Du mangler at trække det fra 100.. ellers giver det ikke det rigtige resultat..

prøv med:

max = 200
nu = 40

Det skulle gerne give 20%.

Det sku have været ((nuværende * 100) / max) :P

Jeg kom lige til at tænke på, thesurfer - man kan jo ikke rigtigt få fat i tmpnavnet før filen faktisk er uploaded ... Kan man?

Jeg ved faktisk ikke hvordan det foregår.. men jeg regner med at dataene skrives til disken, i stedet for hukommelsen..

Hmm.. det ville faktisk være lidt fjollet at skrive det til en tmp fil, for derefter at flytte filen pga fragmentering.. men hvis tmp filen nu ligger på den endelige destination, så serveren bare skal omdøbe filen, burde disken ikke blive fragmenteret af det..

Hvis der ikke kommer en eller anden med dokumentation på hvordan det virker, må man (=dig) bare prøve.. :-)

Nu har jeg lavet et script der virker - i teorien...

Jeg kunne ikke finde nogen måde at få fat i tmp filens navn før filen var blevet uploadede, så jeg konstaterede at temp filen må være den første fil i temp mappen. Og ud fra det virker det faktisk. Nu er problemet bare at jeg ikke kan få adgang til /var/tmp/ på mit webhotel (web10 hosted), så jeg har været nød til at tjekke med en anden mappe, der ikke indeholde tmpfilen, men bare en vilkårlig fil jeg har smidt ind, og ud fra den fil, virker scriptet helt perfekt.

Nu tænker jeg så, om det er muligt at ændre tmp-diret til en mappe jeg har adgang til?

-- nu er tråden jo egentligt gået i en retning hvor den burde ligge i php kategorien:D

Jeg vil tro at det er operativsystemet eller webserveren der bestemmer hvilke mappe der er tmp-mappe.

Jeg mener dog at man i ASP.NET kan vælge hvor filen skal uploades til.. jeg ved bare ikke om ASP.NET uploade til den endelige destination + filnavn, eller om det også er tmp mappen + tmp filnavn..

Jeg tvivler på at du kan skifte din tmp-mappe, hos dit webhotel.. men du kunne jo sende dem en mail.. :-)

Jeg tænkte der måske var en ini_set workaround, så det vil jeg lige prøve at kigge på, men ellers må jeg sende en mail til web10, ja:)

Jeg kender så godt som intet til opsætning af PHP servere.. Jeg har leget en lille smule (men absolut ikke nok) med Apache, for omkring 100 år siden.. :-)

Okay, så vidt jeg har forstået er det ikke muligt at ændre upload_tmp_dir via ini_set da det er en INI-SYSTEM setting, og ikke INI-ALL, så nu har jeg sendt en mail til web10 og hjælp.


Mange tak for hjælpen thesurfer, ole, og w13.
Jeg forestiller mig at pointene går til thesurfer, da det var dig der fik det skåret så meget ud pap for mig, at jeg faktisk forstod det:)

Hehe :-)

Husk på at mit forslag nok ikke er den eneste løsning, hvis det altså overhovedet er en gyldig løsning.. men teorien er der.. :-)

Vent gerne på forslag fra de andre.. de er muligvis hoppet i seng, og er nok først tilbage omkring i morgen eftermiddag.. :-)

- Svar

Man kan kun i IE aflæse filstørrelsen på klienten, så det aflæses på anden måde - så vidt jeg husker, gøres dette også af Perl-scriptet  ;o)

Ahh, jeg har ud fra thesurfers metode researched en smule rundt, og der ser ud til at det er helt og aldeles doable - nu er jeg bare nød til at få fingrene i et webhotel hvor jeg kan tilgå tmp mappen... Alternativet er at jeg sætter min egen server op...

- og læg mærke til, hvad du med denne løsning tvinger serveren ud i  ;o)

Hvert eneste sekund skal serveren aflæse et cookie-navn - og ned i en mappe og finde en session-fil. Når den er fundet, skal den åbnes og læses, hvorefter beregningen skal foretages og resultatet returneres. Og det er kun i hovedtrækkende, hvad serveren spammes med ... hvert sekund!

Man skal efter min mening have _kanon_ gode grunde for at 'misbruge' sin server på den måde - og husk, at du på et webhotel ikke kun misbruger dine egne serverresourcer  ;o)

Oh nej nej, jeg syntes session løsningen var lidt kludret, så jeg er gået helt uden om det og har konstateret at den første fil i tmp-mappen sorteret efter nyeste dato, er den fil vi skal have fingrene i. Om det så virker i praksis ved jeg ikke helt endnu, da det jo i teorien kan lade sig gøre at en persons download går igang før din er gået igang, men hans blev affyret efter din er blevet det.

Ydermere er der ingen grund til at man skal have filens størrelse hvert sekund. Der kan snilt laves en algoritme der ud fra meget få kald, kan få det til at virke næsten lige så præcist.

"Der kan snilt laves en algoritme der ud fra meget få kald, kan få det til at virke næsten lige så præcist." >> Så kan jeg slet ikke se meningen med 'tingen'.

Hvis du nogensinde har arbejdet med upload i andre sammenhænge (f.eks. VB), vil du vide, at der kan være kæmpe forskelle mellem 'hullet-igennem' to brøkdele af et sekund imellem. Laver du bare gennemsnitsberegninger, så er det spildte Guds kræfter på Balle-Lars. Det bliver lige akkurat nummeret bedre end en løsning med en animeret gif  ;o)

Tro mig: Jeg _har_ været der ... og det er der masser andre, der også har  =)

- men jeg vil ikke fraråde dig at lege med 'tingen'. Det er altid bedst, selv at finde ud af, man er igang med noget skidt  ;o)

Idéen med den førnævnte algoritme er at i stedet for at checke for filens nuværende størrelse hvert sekund, eller mindre, så bliver den måske kaldt 2 gange inde for et sekund for at få et average speed, og så kan man tilladese sig at vente 3 sekunder for at lave det næste tjek. Dette sparer man så 1 unødvendigt kald på.

"Hvis du nogensinde har arbejdet med upload i andre sammenhænge (f.eks. VB), vil du vide, at der kan være kæmpe forskelle mellem 'hullet-igennem' to brøkdele af et sekund imellem. Laver du bare gennemsnitsberegninger, så er det spildte Guds kræfter på Balle-Lars. Det bliver lige akkurat nummeret bedre end en løsning med en animeret gif  ;o)"

Jeg må indrømme jeg ikke rigtigt kan finde hoved og hale i det stykke tekst?:D