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.
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).
On Tue, Jul 14, 2009 at 6:34 AM, Christian Bauer
I've started documenting the (uncommitted) performance
Later this week I'm going to roll out these changes on sfwk.org
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.
Please have a look at the doc and tell me what I've been missing.
There is also one more thing we should discuss at some point for Seam 3:
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.
seam-dev mailing list
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597