Plans for Loggerhead

[Martin Albisetti]

On Wed, Jan 7, 2009 at 12:34 AM, Martin Pool <mbp at canonical.com> wrote:
> I do think having a plain interface is important, not only for people
> who have non-js browsers (which may be a small percentage, but not
> zero), but also so that it can be handled by simple screen scraper tools
> and seen by search engines.  Getting google searches to find Loggerhead
> pages is useful for the people doing the searching and builds a network
> effect on bzr.

100% with you. I'd love to be able to open loggerhead on Launchpad to
bots without having it crash and burn an hour later. The non-js
version should not only be plain html, but also very cheap to serve.


> Would it be better having a layer at which these are e.g. python
> dictionaries of strings, and then one layer up they are translated into
> json syntax?  That might be more congenial for Python code that wants to
> use them, and you could feed them into a template library.

It would be better. These are the architectural "details" I have not
thought through yet  :)


>> - Cache the full revision graph in sqlite, so we can access it
>> partially without having to store all of it in memory. Ideally, we'd
>> end up modifying bzrlib to allow partial access, so I'd like to
>> structure this in a way that's easy to drop the sqlite backend later
>> on
>
> I'd rather look to either change the underlying bzr code to perform as
> you need, or do the cache within bzrlib as it will be useful elsewhere.
> It may also eventually be faster to do this cache using facilities like
> indexes that we already have available.

It would be awesome to drop sqlite as a dependency  ;)
Does that mean I can get someone to commit to doing those changes?
Could it be done in a reasonable time frame? (6 months?)


> It would be also good to say pass up last-modified data all the way
> through the stack from bzr to http.  Then we can cache the output; we
> can revalidate without regenerating the whole thing; and as you mention
> we can put squid in front of it.

It would be good.
Currently, we check the tip, and see if it's the same as what we have
cached. If not, we re-generate the cache. Not sure how much cheaper
the last-modified approach would be.


> I know you now have this large and exciting global design
> responsibility, and so somewhat less time for loggerhead.  Maybe we
> should be looking for someone else who could spend more work time on it.

The more, the merrier.
Launchpad says: 116  branches owned by 29 people and 2 teams, 42
commits by 8  people in the last month
We're growing in contributors, but of course, it's never enough  :)


-- 
Martin