The second release candidate was built this afternoon. It contains some fixes and some improvements suggested by PMD and Findbugs. Another major focus was to improve the performance of jaev. This was achieved in reducing the number DNS lookups by introducing a cache for DNS MX record resolution.

This may lead to another nifty feature in the next release candidate, final or 1.1 release. I am planning to introduce a domain suggest function. This may be achieved by using a fix/initial suggestion list and the queries against the DNS lookup cache. If everything works out well the i.e. the Tapestry 5 example may offer a suggest function for e-mail addresses.

So this weekend I read the article about some new Features of the 5.1 Version of the Tapestry framework ...

One of the blogs I am reading on a regular basis is the Tapestry Central blog from Howard Lewis Ship the founder and lead developer of the Tapestry framework. It already provided some really nice ideas and introduced me into some really interesting topics.

So this weekend I read the article about some new Features of the 5.1 Version of the Tapestry framework. And I was really exited to read about the plans to reduce/minimize the traffic over the wire. I am studying this topic for quite a while, since I stumbled across it during a project. The trigger was the Best practices article from the Yahoo developer team.

Since then I was using different approaches and tools to improve the performance of the websites of my clients. One very useful tool is JAWR a Javascript and CSS bundling and compression tool. JAWR offers facilities to join multiple Javascript or CSS files in bundles. Each bundle will be delivered compressed (if possible), in addition very strong cache HTTP headers will be set to the HTTP response, so that the internet infrastructure may cache these files. So the traffic the originating server will be reduced. To prevent nasty caching problems the JAWR framework provides facilities to generate URLs to these bundles which contain a version information, so when the bundle changes, a new URL will be generated.

The very exciting thing about the planned Features in Tapestry 5.1 is, that Tapestry is the first content generating web framework which will provide out the box facilities for this kind of issues.
A great weakness of the JSP and JSF approaches to generate content is, that there is no fast/cheap way to determine a last modified date for a page or a component. So the application can't use the "If-Modified-Since" and "Not Modified" (HTTP status 304) mechanism to provide a lightweight answer for requested resources which have not changed. Maybe Howard Lewis Ship is able to provide this with his Tapestry framework. This would be a great performance boost for any kind of web application.

May very dynamic application don't address the content delivery issues at all. Its quite sad to see, but on the other hand side it's good to see that some frameworks are beginning to address this kind of features.

After nine years and four month at SinnerSchrader I am pretty nervous how this will be. It was my first employment after I graduated at the Fachhochschule Wedel. Hell I will really miss some of the boys and girls! But I am still convinced that this is the time for me to move on.

One of these "new skills" I am preparing is Adobe Flex, which is a framework to create rich clients for the internet based on the Adobe Flashplayer.
Quite an intresting and well designed piece of Software. This is still my first impression I'm pretty sure I will discover some very ugly facets later. I already ran about some bugs with the HTTPService which prevented my from setting the "User-Agent" header on a HTTP GET request. Damn I am demanding I know
But the WoW Armory refused to return pure XML until I pretend to be the Firefox 2.x Browser. WoW Armory is also a pretty interesting piece of software. It offers the facilities to query WoW Characters, Guilds or Items via the Web. If you are using a Firefox browser the WoW Armory returns only a XML which will be rendered with a XSLT style sheet. All the other Browser will get an "interesting" HTML page. Maybe I am blogging about this later.

One last thing left to do for 2009:

Wie man so schön in Deutschland sagt: Einen Guten Rutsch ins neue Jahr!

Friday evening I read about the new version of JSF. The reference implementation (RI) Mojarra made an early draft review (EDR) of Mojarra 2.0 which implements the lastest specification of the JSR-314 which features JavaServer Faces (JSF) 2.0.

I don't want so summarize alle the new little gizmos in the JSF 2.0 spec or the EDR, Ryan Lubke does this in his blog already. There will be a long way to go to finish all the issues of the JSR but I can't stand to comment the one or other thing.

Like i.e. the project stage feature. Damn I am doing this like this for years in my application. It's a wonderful way to tell the application how many secrets have to be kept in this environment.
In a test environment I like the application to be very verbose and tell my of every little affliction, but in productive envorinments the application has to be very reticent. I don't want to tell the bad guys out there all over the internet about the flaws in the application.
One thing I am still missing, which goes hand in hand with project stages in my appliations it the version number. The application provides facilities to access the version number of the application and display it in any page. A wonderful tools to communicate with our QA department. They can check the version history if an issues was solved in the current version deployed on the test and QA system and they don't have to recheck about the version with me every time.

Another nice feature I noticed is, that in JSF 2.0 the component tree may be aware of the head and body areas in a HTML page. So it now should be quite easy to add CSS and Java-Scipts to a page. This may end some nasty implementations to re-parse the rendered output before it's send to the client to add CSS or Java-Scripts to the header. Or worse the tons of inline Java-Script code.
Let's be honest most of the HTML code generated by JSF is quite a horror and the frontend engineers are hating it a long time. Maybe we'll get some really nice HTML code now, so we don't need any more perfomace hacks to accellerate the bad HTML code.

I will keep an eye on the JSF 2.0 spec, it may solve much of the pain I have to today using JSF ...

But I already spent a little time on playing around with Tapestry 5 on my little project. Quit a nice piece of software, but quite some hurdles to get into it. The trivial examples work quite well but I still have some troubles getting my ideas working. But I guess my years of experience are standing in my way now, because I am quite aware of what I am wanting to achieve ...

Maybe this week I have some time to investigate Tapestry 5 more in detail.

Anyway ... today I had a nice discussion with a colleague about this topic. He's a senior front-end developer. This means he is a real pro in HTML, CSS, Java-Script and stuff like this and he's the one who showed me the whole Yahoo! performance stuff. After this discussion I wanted to check some things out in detail.

Stating with this whole website performance an ETag topic opened pandoras box. It's a real mess and lame compromises all over the place. But I have to admit that the whole thing is not as easy as I expected it to be.

Anyway ... today I had a nice discussion with a colleague about this topic. He's a senior front-end developer. This means he is a real pro in HTML, CSS, Java-Script and stuff like this and he's the one who showed me the whole Yahoo! performance stuff. After this discussion I wanted to check some things out in detail.

First I wanted to check if the Apache was sending two different ETags if you have to Apache web servers delivering the content of a website. A simple test with wget verified it:

wget --no-dns-cache -S http://www.a-domain.de/flash/ballons_main.swf
--09:14:26--  http://www.a-domain.de/flash/ballons_main.swf
           => `ballons_main.swf'
Resolving www.a-domain.de... 84.xxx.xxx.x17, 84.xxx.xxx.x33
Connecting to www.a-domain.de|84.xxx.xxx.x17|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Thu, 22 May 2008 07:14:26 GMT
  Last-Modified: Tue, 20 May 2008 15:49:24 GMT
  ETag: "1041e6-7b2c8-6c9fc900"
  Accept-Ranges: bytes
  Content-Length: 504520
  Keep-Alive: timeout=15, max=45
  Connection: Keep-Alive
  Content-Type: application/x-shockwave-flash
Length: 504,520 (493K) [application/x-shockwave-flash]

When requesting the first web server the ETag "1041e6-7b2c8-6c9fc900" war returned ...

wget --no-dns-cache -S http://www.a-domain.de/flash/ballons_main.swf
--09:14:26--  http://www.a-domain.de/flash/ballons_main.swf
           => `ballons_main.swf'
Resolving www.a-domain.de... 84.xxx.xxx.x17, 84.xxx.xxx.x33
Connecting to www.a-domain.de|84.xxx.xxx.x33|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Thu, 22 May 2008 07:14:26 GMT
  Last-Modified: Tue, 20 May 2008 15:49:24 GMT
  ETag: "b824e-7b2c8-6c9fc900"
  Accept-Ranges: bytes
  Content-Length: 504520
  Keep-Alive: timeout=15, max=45
  Connection: Keep-Alive
  Content-Type: application/x-shockwave-flash
Length: 504,520 (493K) [application/x-shockwave-flash]

... after requesting the second web server the ETag "b824e-7b2c8-6c9fc900". So if you do not disable the INode usage for the ETag calculation the whole mechanism will not work. But does this really matter. As you can see the DNS caching was disabled for the test. In a real life situation the DNS caching we be activated and my browser will talk only to one web server and the INode issue won't matter at all.
But if we have multiple web server and the internet browser will only talk to one of them, why do I need the ETag? The Last-Modified header will be enough, won't it?

So my conclusion is use either the Last-Modifed header or the ETag header but using both header makes no really sense at all. This should be right in any case for the Apache HTTPD, the Microsoft IIS or any other web server delivering static content. I also recommend using the Last-Modified because the ETag calculation requires more computing time. There is only one scenario I can provide where the ETag will work and the Last-Modifed Header will not. If someone is changing content and does not modify the last modified time stamp. But this should be rather uncommon.

But how is the situation at dynamic content creation? My favorite web framework is Java Servlets and all related technologies (JSP, JSF, Tapestry, and so on) and after that very disappointing chapter with the ETag I decided to take a closer look at the facilities the servlet and JSP APIs are offering. Another sad very sad story at my actual point of view right now. But for tonight it is enough. Later more about it ...