Excellent start Christian. I have no doubt the enhancements you are introducing are going to be well received and perhaps will even stir up some feedback from Seam users who have gone through the process of optimizing their Seam-based applications.<br>
<br>One point you may want to mention is that users should not be discouraged if they put effort into an optimization and it turns out to have no effect. This disappointment has often discouraged me from pursing optimization techniques in past projects because I just didn't see any blue sky (time and money was the devil's advocate). In light of that, you might want to recommend ways to determine whether you made an improvement. For instance, is there a bandwidth throttle tool you recommend to emulate a latent network or a way to route the request through a known latent network? Testing against localhost often makes it hard to see where things are slow (because everything is so fast).<br>
<br>-Dan<br><br><div class="gmail_quote">On Tue, Jul 14, 2009 at 6:34 AM, Christian Bauer <span dir="ltr"><<a href="mailto:christian.bauer@gmail.com">christian.bauer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've started documenting the (uncommitted) performance improvements I've enabled: <a href="http://www.seamframework.org/Documentation/HTTPClientserverOptimizationStrategies" target="_blank">http://www.seamframework.org/Documentation/HTTPClientserverOptimizationStrategies</a><br>
<br>
Later this week I'm going to roll out these changes on <a href="http://sfwk.org" target="_blank">sfwk.org</a> and we'll see if it all works as expected. I'm also going to integrate the Seam Remoting patch that allows caching of JS interfaces of several components.<br>
<br>
Please have a look at the doc and tell me what I've been missing.<br>
<br>
There is also one more thing we should discuss at some point for Seam 3:<br>
<br>
We are duplicating lots of functionality in Seam that any JAX RS implementation has. We should probably drop SeamResourceServlet and maybe even SeamFilter in Seam3 and rebuild what we need on top of JAX-RS. The downside is that we'd create a dependency on a JAX-RS implementation. OTOH almost anyone might want one of these in the future anyway.<br>
<br>
_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br>