true.
that is why the framework can't be smart enough to do this by it self.
I apologize, in this email I was refering to an earlier email that I
sent out a while ago..
In that email I was asking for framework support for
lastmodified/expires throughout the component tree. So that people
could implement lastmodified/expires at the component level, and the
framework would simply aggregate this information and could tell you the
lastmodified/expires for a whole page, or simply a portion of the
component tree.
That way if I implement a component of some complexity I could scope the
lastmodified/expires logic where it should live ( on that component ),
and have it instantly integrated wherever page or super component it
might be used.
So with "proper" support for lastmodified/expires from the framework,
every page from tapestry could work appropriately with any standard HTTP
cache mechanism. So with some work you can increase the scalability of
your tapestry application, within the component-based framework, not
through any hacks.
Currently I have to implement the lastmodified/expires logic as a filter
ontop of Tapestry that looks for particular urls...
fernando
By the way, we put squid in front of our servers and we have a cache hit
of about 80%. And with some of the client-side-include work that I'll
be integrating, we will get even more!
Howard Lewis Ship wrote:
What is "properly"? That is, when a page is constructed by pulling
data out of some large collection of database entities and stateful
server-side properties, any of which may have changed between
timepoint A and timepoint B, how do you effectively and efficiently
determine that something is "out of date" at timepoint B? It is not a
trivial problem to solve, it may be THE problem in server side web
development.
On 4/26/06, Fernando Padilla <[EMAIL PROTECTED]> wrote:
I can't resist commenting on your "cache" feature :) :)
just support lastModified and expires properly! :) then you can simply
put Squid in front of your server, or we can develop a basic
SquidFilter. :) :)
Brian K. Wallace wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
speed before 5 hits. (feed the masses and all that :-))
In speaking of performance... (I'm off in dream land here, I know... but
I like it there sometimes)
Many moons ago, there was talk of a 'tool' /'utility' that would
basically spider a Tapestry app and get all the generated HTML resulting
in basically a statically generated site. This helps tremendously when
you're running behind a web server that's tuned to serve static content
- - it's what they do and they do it pretty well with no overhead past
itself (meaning no java, no db, etc). I'd like to see if we can't add
some sort of 'cache' attribute to the HTML (somewhere) that would allow
Tapestry to perform this type of "wait, it says to cache it - i've
already generated it, I'll just grab that and use it" processing. This
would also allow Tapestry to build on first access but write out the
generated HTML so the next time a request comes in for it, the web
server would find it first (outside the mapping for Tapestry). Granted
this would only work for pages that were "cache=true" and had no dynamic
components inside it, but for a lot of sites that's enough (especially
outside a 'user' area). If there's a static form, submitting it would
pass back to Tapestry for processing.
I'd see this as only improving performance if you run Tapestry behind
something like Apache. Granted, you'd get a lot of "that's not fair -
you're not comparing our framework to yours if you don't hit your
framework more than once when we have to hit ours every time"
comments... but hey ;-)
My .02
Brian
Howard Lewis Ship wrote:
The basic AOP infrastructure is coming along. I expect the rest to
ramp up pretty quickly once I get that in place, but we're still
talking months. Maybe a useable beta by year's end.
I think I predicted a big performance boost for Tapestry 4 apps vs.
equivalent Tapestry 3 apps. I believe the difference between 4 and 5
will be greater. In fact, I expect OGNL support to be an add on, and
the built-in code will be an improved version of tapestry-prop (from
Tapestry @ JavaForge). I want Tapestry to be extremely high
performance, as one of its differentiators from JSF and Rails.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
stsYXpMZrbap+Q7Jxn+Lh0k=
=xbzo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
