nicht angemeldet
gzip/rar/zip in javascript ?
hallo wissende,
kennt jemand eine möglichkeit, irgendein komprimiertes dateiformat mit NUR javascript zu dekomprimieren, damit der inhalt im browser dargestellt wird ??
folgender hintergedanke:
frameseite, ent-zipper-javascript im parent. links per javascript auf cgi (z.B. fastview.cgi?seite2.htm)
nph-CGI jagt html vor ausgabe durch gzip o.ä., generiert eigenen HTTP-header zur erkennung und schickt ein "zip" zum client.
clientseitiges javascript dekomprimiert das zip und zeigt mit document.write() das HTML innendrin im frame an.
das dürfte einen rasend schnellen seitenaufbau zur folge haben; ausser der client-rechner an sich ist sehr lahm. das nadelöhr internetanbindung wäre zumindest entschärft.
die erste seite mit dem entzipper ist natürlich lahm.
das CGI krieg' ich hin, aber das javascript bestimmt nicht (kaum ahnung).
wer hätte lust, sich da zu beteiligen ? das ganze sollte hinterher als openSource irgendwo frei verfügbar sein für privaten gebrauch.
gruss
florian
-
Hi
Ich wuerde sagen, dass sowas (Dateien auslesen, manipulieren..) mit Javascript normalerweise nicht moeglich ist. Die einzige Moeglichkeit ist signed Javascript.
siehe: <../../sfausles/tsfa_tci.htm#a4>
Tschau Holger-
hi,
gerade mal nachgelesen, denke dass das abrufen einer URL nicht unter dateien auslesen fällt.
als javascript-laie würde ich einfach versuchen, irgendwie den rückgabewert einer art HTTP-get-funktion einem skalar zuzuordnen und den dann durch den zip-alg. jagen, dessen output direkt auf document.write() geht. (ob javascript das wohl kann mit dem "HTTP-get"????). dateizugriffe kommen da nicht vor, und in den arbeitsspeicher kann J.Scr. ja schreiben.
gruss
florianHi
Ich wuerde sagen, dass sowas (Dateien auslesen, manipulieren..) mit Javascript normalerweise nicht moeglich ist. Die einzige Moeglichkeit ist signed Javascript.
siehe: <../../sfausles/tsfa_tci.htm#a4>
Tschau Holger-
Hi Florian
Wenn ich dich aber richtig verstanden habe, willst du mit Javascript die Entpackroutine schreiben und da liegt das Problem, weil diese Routine natuerlich irgendwie die Datei auslesen und verarbeiten muss und das geht nicht!Tschau Holger
-
hi,
seit wann ist ein socket eine datei?
oder ist das einfach bei JScr schlecht gelöst worden?florian
Hi Florian
Wenn ich dich aber richtig verstanden habe, willst du mit Javascript die Entpackroutine schreiben und da liegt das Problem, weil diese Routine natuerlich irgendwie die Datei auslesen und verarbeiten muss und das geht nicht!Tschau Holger
-
-
-
-
hi
das ganze klingt ja recht net, aber was erhoffst du dir davon?? der geschwindigkeitsvorteil sollte sich klar in grenzen halten, da der server auch erstmal komprimieren muss, außerdem wäre das dekomprimieren ja clientabhängig, also von der rechenpower des clients abhängig...
... mal ganz abgesehen, das ich kein weg sehe dateien mit javascript zu dekomprimieren (wenn wärs ja eh nur das html)...
... nochwas: ich surfe immer mit abgeschalteten java und javascript!
dennoch gute idee wars ...
cu
Andreas
hallo wissende,
kennt jemand eine möglichkeit, irgendein komprimiertes dateiformat mit NUR javascript zu dekomprimieren, damit der inhalt im browser dargestellt wird ??
folgender hintergedanke:
frameseite, ent-zipper-javascript im parent. links per javascript auf cgi (z.B. fastview.cgi?seite2.htm)
nph-CGI jagt html vor ausgabe durch gzip o.ä., generiert eigenen HTTP-header zur erkennung und schickt ein "zip" zum client.
clientseitiges javascript dekomprimiert das zip und zeigt mit document.write() das HTML innendrin im frame an.das dürfte einen rasend schnellen seitenaufbau zur folge haben; ausser der client-rechner an sich ist sehr lahm. das nadelöhr internetanbindung wäre zumindest entschärft.
die erste seite mit dem entzipper ist natürlich lahm.das CGI krieg' ich hin, aber das javascript bestimmt nicht (kaum ahnung).
wer hätte lust, sich da zu beteiligen ? das ganze sollte hinterher als openSource irgendwo frei verfügbar sein für privaten gebrauch.gruss
florian
-
hi
das ganze klingt ja recht net, aber was erhoffst du dir davon?? der geschwindigkeitsvorteil sollte sich klar in grenzen halten, da der server auch erstmal komprimieren muss, außerdem wäre das dekomprimieren ja clientabhängig, also von der rechenpower des clients abhängig...
das nadelöhr ist meist der connect und nicht die rechenpower der heimischen maschine.
ich habe das auf dem server getestet und brauche für eine durschschnittliche htmldatei unter 0.2 usertime, das ist nichtmal spürbar.gruss
florian... mal ganz abgesehen, das ich kein weg sehe dateien mit javascript zu dekomprimieren (wenn wärs ja eh nur das html)...
... nochwas: ich surfe immer mit abgeschalteten java und javascript!
dennoch gute idee wars ...
cu
Andreas
-