Plans for Loggerhead

[Robert Collins]

On Wed, 2009-01-07 at 00:22 -0200, Martin Albisetti wrote:
> On Wed, Jan 7, 2009 at 12:15 AM, Robert Collins
> <robertc at robertcollins.net> wrote:
> > High level questions:
> >  - json objects are usable by browser side code as-in ?
> 
> Used to render the actual html via javascript.

Where does this rendering take place? On the loggerhead server, or in
the browser?

> >  - You seem to suggest a _lot_ of new caching activity in loggerhead,
> >   which scares me badly. Have I misunderstood?
> 
> I suggest the possibility to cache  :)
> Slapping squid in front of Loggerhead with this way of doing things
> should make it quite scalable.

Ok, so if loggerhead isn't caching the objects, but squid and browser
caches are thats fine :).

> 
> > Random thoughts:
> >  - loggerheadlib should be 'bzrlib.plugins.loggerhead
> 
> Sounds reasonable. I don't exactly know what the consequences of that
> is, but it sounds reasonable :)
> 
> 
> >  - how does this help with working with multiple branches at once in
> >   loggerhead?
> 
> The biggest difference would be that we would *just* generate the
> jsons server-side, and the rendering would be done client-side. This
> will relieve us of a *lot* of processing. It gets more powerful with
> multiple related branches if we cache the json files (however we
> choose to do it), as you would only need to get the information for a
> revision once.

I'd be extremely wary of overlapping with bzrlib here; fundamentally the
basics of loggerhead should be very thinly layered on bzrlib, if
something is too slow to show to a user in web time using bzrlib
directly, anything added on top is just complexity that will interfere
as bzrlib gets fixed to be fast enough. This has happened a few times
already - and when I look at loggerhead performance on brisbane core its
mainly using convoluted approaches on top of bzrlib api's that are
slower than they should be on production branches.

-Rob



-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090107/6ee0080c/attachment.pgp