launchpad-dev team mailing list archive

[Graham Binns <graham@xxxxxxxxxxxxx>]

On 16 February 2010 11:50, Abel Deuring <abel.deuring@xxxxxxxxxxxxx> wrote:
> 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.
>

I like this idea, but we rejected it early on because there's some
data in Apport blobs that can be used to populate the +filebug form.

Of course,  we could add it after the fact, for example updating the
bug description to be apport description + user description and so on.
I'm ambivalent about doing that though.

That said, it wouldn't be hard to have the job class tied to the bug
once it's been filed and then, once the job's complete, updating the
bug with the data from the blob.

I'll look into how the data from the blob is used again (I can't
remember why we rejected this approach before; I'm assuming there's a
good reason that I've forgotten). If it's possible to do it this way
then maybe that's how we should proceeed.

-- 
Graham Binns | PGP Key: EC66FA7D