launchpad-dev team mailing list archive

[Abel Deuring <abel.deuring@xxxxxxxxxxxxx>]

On 16.02.2010 11:43, Michael Nelson wrote:
> On Tue, Feb 16, 2010 at 11:06 AM, Graham Binns <graham@xxxxxxxxxxxxx> wrote:
>> Hi folks,
>>
>> I'm currently working on the Apport blob processing story [1], whose
>> aim is to make sure that +filebug doesn't time out when apport uploads
>> an enormous blob (the problem being that the blob is currently
>> processed in-request, so the bigger ones cause timeouts fairly
>> regularly).
>>
>> I've already written the code for processing the blobs server-side
>> using the Jobs system, so all that's left is to make +filebug aware of
>> that system. The idea is that +filebug will check to see whether the
>> blob has been processed before allowing the user to proceed. If it
>> hasn't, +filebug will wait a while and check again; if it has,
>> +filebug will use the processed data as normal.
>>
>> The idea is that we'll do this using Javascript eventually, but in the
> 
> Hi Graham,
> 
> Do you mean that you'll do both the polling (easy) and the automatic
> updating of the bug page (time consuming) with JS eventually? And if
> so:
> 
>> first iteration of this we're going to do it with meta refresh tags,
>> since that's reasonably quick to develop, meanting that if we don't
>> have time to finish the JS work this cycle the UI that does land will
>> still be useful.
> 
> I'm wondering how much extra effort would be involved to do the
> polling via JS on the bug page itself (with a message similar to
> yours: "Launchpad is processing the extra bug data you uploaded" and
> then when the info is ready, simply change that message to "Launchpad
> has finished processing the extra bug data you uploaded. [[Refresh]]",
> where the refresh link would simply reload the bug page (as a first
> cut)?
> 
> This would allow people to work with their bug while waiting (although
> that might not be so useful given the timeframe) and perhaps be closer
> to the final result that you want to end up with?

I'm writing this without checking how we currently tie the apport data
to the bug, so I might be talking nonsense, but: Couldn't we simply let
the user file the bug and let the apport job add the interesting data
later? OK, this makes the apport job processing more complex. It must
deal with the situation that the bug has not yet been filed so that the
initial bug description can be generated by the apport job, as well as
with the situation that data must be added to an existing bug.

Abel