On Mon, Feb 15, 2010 at 10:04:24AM -0500, Evan Daniel wrote: > On Mon, Feb 15, 2010 at 9:32 AM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: > > On Sunday 14 February 2010 00:52:00 steve oliver wrote: > >> I've been following this for a while, and it took me a bit to see both > >> sides. > >> > >> Whatever the project ends up doing in the long run with the web > >> interface(s), the first thing that should be done even if fproxy doesn't > >> change at all, is to move the HTML out of the java code, and start using a > >> templating engine of some kind. HTML, while intended for structure, is a > >> presentational system for displaying data, it should not be mixed in with > >> backend code that actually generates that data. > > > > This has been suggested in the past. Generally it hasn't happened because: > > - It would significantly increase complexity in the short run. > > - It would reduce performance. > > - It would increase the size of the download by approx 500K. > > > > It may well be that all of these reasons are now obsolete. Our download is > > over 9MB already, so the last is irrelevant. Our HTMLNode stuff is not > > without overhead, so the other two may be invalid too. > > Also, for most pages that have a perceptible delay, I think the delay > has more to do with retrieving things from a database or decoding > Freenet data than it does with HTML generation. >
Last time I checked lock contention was the problem... hence we have 'cached' versions of some problematic pages (like the statistics one). Florent
