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]
