The code for gzipping swf is still in the SWF responder , so for delivering the "object" file for the app, I forced gzip encoding flag to true if the runtime is dhtml. It seems to work, and I didn't dig deeper to see what is happening, but I believe all the logic is still working to store the gzipped file in the cache and retrieve it, based on the compiler encoding flag.
In DHTML we actually serve the LFC via a separate responder, so I manually gzip the lfc there and write it to disk if needed, otherwise serve up the gzipped lfc. On 11/13/06, David Temkin <[EMAIL PROTECTED]> wrote:
could you tell us more about how this works, where it's implemented, and how it relates to old LPS code for SWF5? On Nov 13, 2006, at 7:06 PM, Henry Minsky wrote: > I've got a patch which does the compression in the LPS servlet, if > anyone wants to figure out how to test it.. > > > On 11/13/06, Henry Minsky <[EMAIL PROTECTED]> wrote: >> In any event, this is too risky to go in to the upcoming release. >> >> On 11/13/06, Henry Minsky <[EMAIL PROTECTED]> wrote: >> > I wonder if the servlet container is smart enough to notice that if >> > the responding servlet indicates a "gzip" encoding in its >> header, that >> > it will not try to compress it again as it send s it. >> > >> > >> > >> > On 11/13/06, Henry Minsky <[EMAIL PROTECTED]> wrote: >> > > It does seem like it is asking for trouble. >> > > >> > > On 11/13/06, P T Withington <[EMAIL PROTECTED]> wrote: >> > > > That doesn't make sense to me. >> > > > >> > > > Isn't compression for DHTML between the web server and the web >> > > > client? If we do compression in our applet, what happens when >> > > > someone turns on compression in their container? Double >> compression, >> > > > and lossage? >> > > > >> > > > I think I can see it made sense to do compression in our >> applet for >> > > > swf because we were talking to a plug-in, not to a web server. >> > > > >> > > > But, what happens when we deliver a compressed swf via a web >> server >> > > > that is set to do compression? Does the swf get recompressed >> > > > (wasting cpu cycles on both the client and the server)? >> > > > >> > > > On 2006-11-13, at 21:24 EST, David Temkin wrote: >> > > > >> > > > > In the case that it's a server-deployed app, we should >> handle this >> > > > > ourselves inside of LPS (just as we did for SWF5 apps that >> were >> > > > > gzipped). It's likely that there is code (now defunct) >> that could >> > > > > do this, including caching the compressed app and serving >> it up >> > > > > with the correct headers. >> > > > > >> > > > > In the case that it's a SOLO app, we should document how >> to do this >> > > > > with the Apache Web Server or similar. >> > > > > >> > > > > >> > > > > On Nov 13, 2006, at 5:56 PM, Benjamin Shine wrote: >> > > > > >> > > > >> >> > > > >> It would be ever so nice if the platform could handle this >> > > > >> transparently for us, without relying on application >> container >> > > > >> configuration. >> > > > >> >> > > > >> On Nov 13, 2006, at 8:42 AM, Henry Minsky wrote: >> > > > >> >> > > > >>> here's a note I sent in March with a config for tomcat >> > > > >>> >> > > > >>> >> > > > >>> Instructions: >> > > > >>> >> > > > >>> Restart the Tomcat, and then you can see if it is >> working by >> > > > >>> clearing >> > > > >>> the browser cache, and >> > > > >>> loading the demo dhtml app. In LiveHTTPHeaders in >> Firefox you >> > > > >>> should >> > > > >>> see headers like this >> > > > >>> >> > > > >>> GET /lps-legals/lps/includes/lfc/lzdataset.js HTTP/1.1 >> > > > >>> Host: localhost:8080 >> > > > >>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >> > > > >>> rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 >> > > > >>> Accept: */* >> > > > >>> Accept-Language: en-us,en;q=0.5 >> > > > >>> Accept-Encoding: gzip,deflate >> > > > >>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >> > > > >>> Keep-Alive: 300 >> > > > >>> Connection: keep-alive >> > > > >>> Referer: http://localhost:8080/lps-legals/apps/et/app.lzx? >> > > > >>> lzt=dhtml&debug=y&lzr=dhtml >> > > > >>> >> > > > >>> HTTP/1.x 200 OK >> > > > >>> Etag: W/"12841-1141441325754" >> > > > >>> Last-Modified: Sat, 04 Mar 2006 03:02:05 GMT >> > > > >>> Content-Type: text/javascript >> > > > >>> Transfer-Encoding: chunked >> > > > >>> Content-Encoding: gzip >> > > > >>> Vary: Accept-Encoding >> > > > >>> Date: Sat, 04 Mar 2006 22:49:45 GMT >> > > > >>> Server: Apache-Coyote/1.1 >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> server.xml: >> > > > >>> >> > > > >>> >> > > > >>> <Service name="Catalina"> >> > > > >>> <Connector acceptCount="100" connectionTimeout="20000" >> > > > >>> disableUploadTimeout="true" port="8080" redirectPort="8443" >> > > > >>> >> > > > >>> compression="on" >> > > > >>> compressionMinSize="2048" >> > > > >>> noCompressionUserAgents="gozilla, traviata" >> > > > >>> compressableMimeType="text/html,text/ >> xml,text/ >> > > > >>> javascript,application/x-javascript,application/javascript" >> > > > >>>> >> > > > >>> </Connector> >> > > > >>> <Connector acceptCount="100" disableUploadTimeout="true" >> > > > >>> port="8443" scheme="https" secure="true" sslProtocol="TLS" >> > > > >>> keystoreFile="conf/lzkeystore" keystorePass="changeit" >> > > > >>> compression="on" >> > > > >>> compressionMinSize="2048" >> > > > >>> noCompressionUserAgents="gozilla, traviata" >> > > > >>> compressableMimeType="text/html,text/ >> xml,text/ >> > > > >>> javascript,application/x-javascript,application/javascript" >> > > > >>> >> > > > >>> >> > > > >>>> >> > > > >>> </Connector> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> On 11/13/06, David Temkin <[EMAIL PROTECTED]> wrote: >> > > > >>>> When documenting this, we need to discuss, right up >> front, the >> > > > >>>> importance of having gzip compression switched on for >> the HTTP >> > > > >>>> server. There is an enormous size difference between >> compressed and >> > > > >>>> uncompressed, and this isn't an issue for SWF, which >> has internal >> > > > >>>> gzip compression. >> > > > >>>> >> > > > >>>> When serving from LPS, the Javascript should be >> automatically >> > > > >>>> gzipped. It is, right? >> > > > >>>> >> > > > >>>> - D. >> > > > >>>> >> > > > >>>> >> > > > >>>> On Nov 13, 2006, at 7:52 AM, Henry Minsky wrote: >> > > > >>>> >> > > > >>>> > Can anyone tell me what they think is required for >> DHTML SOLO >> > > > >>>> deploy? >> > > > >>>> > That is, what >> > > > >>>> > auxiliary include files are needed? >> > > > >>>> > >> > > > >>>> > Since we serve up the LFC and the app as separate >> files in >> > > > >>>> DHTML, the >> > > > >>>> > new SOLO wizard will at least have to write out >> copies of >> > > > >>>> static files >> > > > >>>> > for these. >> > > > >>>> > >> > > > >>>> > For reference the current swf solo wizard makes >> > > > >>>> > >> > > > >>>> > 1) recursive copy of all files in the directory in >> which the app >> > > > >>>> > resides, and also includes >> > > > >>>> > 2) An html wrapper file (app.swf.html) >> > > > >>>> > >> > > > >>>> > 3) these include files >> > > > >>>> > filenames.add("lps/includes/embed.js"); >> > > > >>>> > filenames.add("lps/includes/h.html"); >> > > > >>>> > filenames.add("lps/includes/h.swf"); >> > > > >>>> > filenames.add("lps/includes/vbembed.js"); >> > > > >>>> > >> > > > >>>> > I will make a master list of what needs to be >> packaged up, and >> > > > >>>> make >> > > > >>>> > fork a version of the >> > > > >>>> > SWF solo deployment tool for DHTML. >> > > > >>>> > >> > > > >>>> > >> > > > >>>> > >> > > > >>>> > >> > > > >>>> > -- >> > > > >>>> > Henry Minsky >> > > > >>>> > Software Architect >> > > > >>>> > [EMAIL PROTECTED] >> > > > >>>> >> > > > >>>> >> > > > >>> >> > > > >>> >> > > > >>> -- >> > > > >>> Henry Minsky >> > > > >>> Software Architect >> > > > >>> [EMAIL PROTECTED] >> > > > >> >> > > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > Henry Minsky >> > > Software Architect >> > > [EMAIL PROTECTED] >> > > >> > >> > >> > -- >> > Henry Minsky >> > Software Architect >> > [EMAIL PROTECTED] >> > >> >> >> -- >> Henry Minsky >> Software Architect >> [EMAIL PROTECTED] >> > > > -- > Henry Minsky > Software Architect > [EMAIL PROTECTED]
-- Henry Minsky Software Architect [EMAIL PROTECTED]
