Plans for Loggerhead

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> Martin Albisetti wrote:
>> On Wed, Jan 7, 2009 at 4:33 AM, Aaron Bentley <aaron at aaronbentley.com> wrote:
>>> I don't understand why going fully Json is a win here.  I could
>>> understand deferring generating things we might not need, but going
>>> fully Json is overkill for that.
>> What do you think would be better?
> 
>> My take on it is:
>> - No more rendering enormous HTMLs
> 
> But wouldn't rendering equivalent JSON be similarly enormous, and
> wouldn't we have to render the HTML server-side for the initial page
> view anyhow?
> 
>> - Can be used by any other app (in a way, like the xmloutput plugin)
> 
> Sure, nice to have.
> 
>> - Simplifies caching
> 
> Not sure I really get that.  Do you mean because if the same object
> appears on multiple pages, we win by caching the object once?
> 
> It just seems to me that if you have a problem and you solve it with
> JSON, now you have two problems, and if you add Javascript then you have
> three problems.
> 
> Aaron

I'm guessing Martin's idea is that you can write out "simple" JSON
objects, and have some javascript that is running on the clients machine
to actually do the rendering.

So you end up "scaling up" the rendering portion by farming it out to
every client that connects, rather than doing any rendering on the
server side.

There is a similar amount of actual HTML rendering, but it is being done
by N clients, rather than 1 server.

That said, I don't really know what the rendering bottlenecks are. It
certainly seems that most pages are "mostly static" anyway, so you could
cache at the HTML layer until a branch's tip revision changes.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklk/+IACgkQJdeBCYSNAAMTugCgtgP+Wm1QcscdF83uOAIifdIH
jQ8AnRhwOLQaXPK8C98bpbn7c9MQuaRp
=pCHO
-----END PGP SIGNATURE-----