Plans for Loggerhead

[Jonathan Lange]

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

On Wed, Jan 7, 2009 at 12:58 PM, Martin Albisetti  wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org

iEYEARECAAYFAklkEVUACgkQX+0xPtMTonxOqgCfTUHf89k9DixSSZtANSKe61of
zggAoMQ9UR7Jv7V13q4kCgNQroeJZ77K
=EudU
-----END PGP SIGNATURE-----

...
> So, my proposal is to develop a loggerheadlib, something completely
> new, fully tested, which, at it's higher level returns json objects.

This sounds eminently sensible.

> On top of that, we can have a simple plain html interface which is
> rendered by parsing these jsons internally for the
> javascript-impaired, and a nice ajax-based interface with all the
> coolness and server-side processing savings that it gives us.

This still sounds good.

> I haven't thought out all the details, but this is more or less what
> I've come up with (some of them by bouncing ideas off of mwhudson):
>

The scope of the library seems unclear to me. What sort of things
definitely do *not* go into the library, but rather into loggerhead
itself? What users do you imagine, other than loggerhead and
plain-html?

Also, perhaps it should be packaged as a bzrlib plugin, even though it
might not add any new commands.

> - Generate one json file per revision, which contains all the
> information about it, excluding the diffs. Doing this will let us
> generate it once, and serve it statically from then on. It also
> potentially lets us cache it client-side, so we don't have to fetch
> information we already did

I guess this is the sort of scope question I mean. Is it a simple JSON
generator, or does it also handle caching?

> My plan is to focus the next release of Loggerhead on making the
> serve-branches script use a config file (using bzr's config methods
> and format, possibly using locations.conf), so we can completely
> replace/remove start/stop-loggerhead, which has been un-loved since
> Micheal brought on the serve-branches goodness.
> Once that's out of the way, I plan to dive into restructuring the
> internals, and slowly move from what we have to the new code.
>

Awesome plan.

jml