launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Oct 5, 2011 at 5:55 PM, Stuart Bishop
<stuart.bishop@xxxxxxxxxxxxx> wrote:
> On Tue, Oct 4, 2011 at 4:54 PM, Robert Collins
> <robertc@xxxxxxxxxxxxxxxxx> wrote:
>
>> Its my belief that we will still have *enough* greppability, and the
>> benefits of easier extensions to the oops format will outweigh the
>> downsides.
>
> My concern isn't the greppability, but just general readability. Not
> everyone will have a system setup to render an OOPS to something
> readable. I just had the pleasure of being handed a raw OOPS from ISD
> and just trying to read raw JSON is painful but doable. Reading raw
> BSON will be impossible. People are not going to write their renderer
> until *after* they have adopted the OOPS system, and people are not
> going to adopt the OOPS system if they can't make use of the OOPS
> reports.

I wouldn't expect users to write renderers initially: they should
deploy oops-tools, or in future oops-repository. Only very high volume
sites will need something different, and they can do that to get
incremenal benefits after initial adoption. I thought ISD used rfc822
oopses; I'll need to chat to selene I guess :)

> Given we still need the RFC822 style format for readable raw reports,
> what is the benefit of having a BSON or JSON format in addition?

Simpler, higher fidelity transport from appserver to oops-tools. We
don't need the rfc822 format at all once:
 - we've migrated across our production systems
 - we've changed one place (attachOopses) to something in-between.
E.g. attachOopses could use json and elide binary content - not
something we'd want in production, but good enough for showing a
developer of a test case.

-Rob