-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Padilla wrote: > > Howard Lewis Ship wrote: > >> I suspect that, going forward, full page renders will often be the >> exception, rather than the rule. That is, you'll have a full page >> render, then a series of partial renders. In many cases, the result >> sent back to the client will not even be HTML markup, but will be an >> (XML?) data stream interpreted by JavaScript running in the browser. > > ** client-side-inclde > Interesting. I have been waiting for the concept of Client-Side-Include > for a while, and maybe tapestry will be build totally around this > concept in the future. For now I just created tapestry components to do > so client-side-include, but then I had to create simple pages just to > render the desired html fragment. > > > ** last-modified > I am not sure if I have mentioned it before, but please as you guys are > thinking about the framework please work in proper support for > last-modified checking! and expires setting! for any render/request. > This simple technique can easy multiply the number of users the system > can handle, for zero cost ( if you were already planning on rendering > everything anyhow ). > > I have been dreaming of refactoring the rewind cycle operation to add a > last-modified cycle, that would walk through the tree and ask each > component it's last-modified time, and then aggregate that information > somehow to determine the page's last-modified time. Then determine > after that if we actually go through the final render step. This saves > resources all around ( cpu, memory, response time, bandwidth ). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
I have no comment on client-side-includes - outside of js I must admit I've either never had the need for them and/or I just don't quite grasp the concept. Full vs. partial renderers, yes. Much past that and I think I must be missing a point or two somewhere. As for last-modified... I have two separate thoughts. I'd definitely like to be able to put a cache pragma on a page and have that page "built once, displayed over and over" (little borrowing of the Java mantra with a tweak for caching purposes :-)). Delivering a cached page will (should?) always be faster than a completely generated page. I'd also like to be able to go back in time and resurrect the 'generate static HTML from Tapestry application' thought. Having a web-server deliver static content will usually (usual caveats: config, load, etc) be faster and less resource intensive than asking a servlet container to do so. I view both of these as separate 'wishes', but both designed to do two things: speed up delivery of content to the client, and reduce load on the server. The problem with your description of a 'last-modified' process of asking each component what it's last-modified time was is: 1. With caching enabled, the question is irrelevant. 2. With caching disabled, the question could be irrelevant - it depends on what the component does. If the component retrieves the latest entries from a database, the component may not have changed - but the entries may have. This would require the component to build itself in order to know if it had truly changed. Past that, you aren't saving much. Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEPVItaCoPKRow/gARAoJtAJ9016W1pKpu98OYX8TsErUUW7L9yQCglhj5 TXv16cN2F6blStzQbYBdLFw= =AnOO -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
