Re: [Laszlo-dev] SOLO DHTML deployment

[David Temkin]

No.

It's exactly the same thing we did with LPS. In fact, there is  
special case code in LPS that does the right thing for browsers that  
claim to handle gzip, but do not. You can't just "switch on  
compression in the container" and expect it to work.

LPS talks to the Web browser, which decompresses the gzipped content  
and caches it. Then, it passes the content to Flash. But it's the  
browser that does the decompression.

On Nov 13, 2006, at 6:52 PM, P T Withington 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]