The Socorro UI must be changed to accommodate dropping the dump tables. See wiki for design (URL field on this bug) The /report/index will have DB access removed and will instead create an HTML shell that retrieves the crash report via compressed JSON, parses the frames and modules data, and updates the display. Eventually, this same codepath would include extra information form the DB, if the user had the correct authorization. The JSON will not have any sensitive information in it.

Here is a sample crash report. Notes: Multi-line strings like the dump are JSON encoded, so their is a literal newline. Dates - Should we do ISO 8601 or an integer (unix time)? Fields and Field Names, feel free to change these or add to then. This is roughly what current page shows.

Fixed bad JSON - was missing a quotation mark

Adding a 2nd attachment which is a full gzip example. It includes the cooked dump in it.

FWIW, after reading Lars' blog post, I think the JSON->HTML should happen in PHP, not client-side, so that we don't require JavaScript to be enabled just to view crash reports. Seems unnecessary. That being said, I would like the JSON for a report to be accessible via some URL so we could do other interesting things.

Moving the gzip processing to the client side offloads this CPU heavy activity from the webheads. I was planning on using it to detect when pending jobs are ready, etc.

Seems like a crappy tradeoff for making the website pretty inaccessible to anyone without JS. Plus, we probably have to be a lot more careful about website a11y if the entire page is built via JS.

Context: This week we get about 10K page views a day. It's a QA/Dev app. For plugins, 88% of users have Java and 93% have Flash. I don't have metrics for JS enabled. Accessibility: I didn't test the prototype in any screen readers, but I did a cursory check to see if JAWS and orca supported XHR. They seem to. We can add WAI-ARIA hints like aria-live='true'. rdoherty is leading the webdev team in a WAI-ARIA initiative. Scope: I can include a link to a static version of this page in a NOSCRIPT tag. It just increases the scope of the work. Currently the PHP layer is decoupled from the dump storage locations, which is nice. This requirement would change that. I feel like JavaScript enabled is an acceptable requirement for this tool. Supporting no script is a totally valid point and I'm wiling to redesign / increase the scope, but I want to make sure it's cost effective.

Seems like we should allow both to be possible. Can we: 1. default to client-side to save cycles 2. provide a manual link to the unzipped json (php controller) 3. use that same unzipped link for users without js

I've updated http://code.google.com/p/socorro/wiki/DumpingDumpTables * Staying with server side dump parsing, changed client side stuff to 'possible enhancement' * Adding <link rel='alternate' type='application/json' href='/reporter/dumps/cdaa07ae-475b-11dd-8dfa-001cc45a2ce4.jsonz' /> to report/index for programatic access to JSON files we can revisit when we fix 414258, 422945, etc

Comment on attachment 374109 [details] [diff] [review] First attempt removes DB access to dumps and uses JSON dump This works for me but we should document config changes (and looks like you have) for deployment and also test after the dumps migration to verify that all preexisting reports work correctly.

done!