On Wed, Oct 5, 2011 at 5:55 PM, Stuart Bishop <stuart.bis...@canonical.com> wrote: > On Tue, Oct 4, 2011 at 4:54 PM, Robert Collins > <robe...@robertcollins.net> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
