Chris’ Musings

For a while, I have been looking (googling) for a way to serve up precompressed files. I have the server configured to compress files on the fly; but I knew there was a way to precompress files. Since I’m not an apache url rewriting expert, this one eluded me.

However, I just ran across a talk on MySql performance and scalability (take a read it has some good real world knowledge). The gem for me was at the end of the presentation on the last slide.

AddEncoding gzip .gzip
# If the user accepts gzip data
RewriteCond %{HTTP:Accept-Encoding} gzip
 
# … and we have a .gzip version of the file
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}.gzip -f
 
# then serve that instead of the original file
RewriteRule ^(.*)$ $1.gzip [L]

I have googled for that for far too long. It’s simple now that I see it, I just wasn’t able to put it all together for some reason. Guess I was expecting something more complicated. Anyway, I’m jotting it down here so I don’t forget (or the link goes away for some reason). I want to implement this real soon.

For our internally developed application framework for GWT apps, we want to use RunAsync heavily. We have pushed as much common code to the framework as possible (that’s what frameworks are there for). So developing new screens is really a breeze. Anyway, we wanted to push the RunAsync into the framework so that developers don’t have to think or even now about it.

However, this doesn’t seem possible with the current implementation. Basically, the split point is where the physicaly code split occurs. Which is logical. We were hoping that a class hierarchy would be taken into account. For example:

public abstract class AbstractClass {
 
  public abstract void doActualWork(Callback cb);
 
  public void doAsyncCall(final Callback cb){
      GWT.runAsync(new RunAsyncCallback(){
         public void onFailure(Throwable err){
            Window.alert("code download failure");
         }
 
         public void onSuccess(){
            doActualWork(cb);
         }
      });
  }
 
}
 
public class FirstClass extends AbstractClass{
   public void doActualWork(Callback cb){
     //does actually work and calls Callback
   }
 
}
 
public class SecondClass extends AbstractClass{
   public void doActualWork(Callback cb){
     //does some other actually work and calls Callback
   }
 
}

When I have the concrete implementation of doAsyncCall(Callback cb) in
AbstractClass, I get 1 split point. When I move the implementation to
each of the sub classes (making the method abstract in AbstractClass),
I get two split points.

Don’t get me wrong, we love the new feature. Here’s hoping for a future enhancement So for now, I guess every developer will need to know about split points. Not a big deal, just one more thing to remember.