Loggerhead directions

[Ian Clatworthy]

On 04/04/10 05:10, Kapil Thangavelu wrote:
>
>
> On Fri, Apr 2, 2010 at 8:58 PM, Ian Clatworthy
> <ian.clatworthy at canonical.com <mailto:ian.clatworthy at canonical.com>> wrote:
>
>     On 01/04/10 18:10, Kapil Thangavelu wrote:
>
>         Its really not clear to me what value for loggerhead, which is
>         pretty
>         close to barebones wsgi, adopting a framework brings for the
>         goals of
>         making it fast and packaged?
>
>
>     For those goals, very little.
>
> Are there other goals for loggerhead that a framework adoption with
> assist with?

I have some ideas (see below) on where Loggerhead should go. I'd 
certainly like to hear from others though ...

    If Loggerhead had an extension architecture where bzr plugins could
    add new tabs or actions to existing tabs, what would *you* do with
    that capability?

IMO, if loggerhead remains a web-based branch history/content viewer, it 
probably won't require much beyond wsgi+templating+i18n. At the other 
extreme, loggerhead could become a web-based implementation of Bazaar 
Explorer + QBzr! :-)

In terms of direction, I would like to see Loggerhead being much better 
at *showcasing* a collection of branches as a project. To be more 
explicit, rather than the current 2 or 3 tabs (Changes, Files, Help), 
I'd like to see Loggerhead give you 5 +/- 2 tabs, much like a typical 
web site. For example, the tabs for a Python project might be:

* Home
* Docs
* Source
* Downloads
* License

where heuristics were used something like this:

* Home would render README(.txt)
* Docs would render docs/index.txt (or docs/_build/html/index.html for 
projects using Sphinx)
* Source would show "Files"
* Downloads would show "Changes" and make it easy to download the tip
   and tagged versions in the history
* License would render LICENSE(.txt) or grab the license metadata
   from setup.py say.

If viewing a shared repository or loom, I'd like:

* a combo-box for selecting the current branch or thread
* a way of seeing the diff between different branches or threads.

In summary, I'd like to keep Loggerhead's emphasis on browsing (rather 
than operating on) repositories and branches. Even so, I can imagine 
that framework goodies like URL mapping, form handling and even security 
being of potential benefit. If we opened it up so others could add tabs 
or actions, then my gut feel is that the benefits of a framework *ought* 
to be a net win over a bare-bones approach.

Ian C.