I've also read Fernando's previous email and it looks like a very interesting idea. However, i see a few problems: - you can't tell which sub-components will render until you actually render their containing component. So, if this must happen, what exactly are the gains? Are you interested in network traffic, server load, or both? - How exactly will people implement lastmodified/expires at the component level? It seems it will always depend on the context on which each component is used and so it cannot be implemented at that level.
The way i see it, this would have to be addressed at the page level, meaning that the user will have to implement all the lastmodified-expires logic on his own. But it still is a step forward. >From Fernando Padilla <[EMAIL PROTECTED]>: > 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] > > -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
