bug#37168: debbugs: Make bug list update asynchronous

bug#37168: debbugs: Make bug list update asynchronous

[Stefan Kangas]

Severity: wishlist

When I type:

M-x debbugs-gnu RET ,minor,wishlist RET

It takes a long time to load on my machine, and it freezes my entire
Emacs session while I wait.  It would be very nice if this operation
could be made to work asynchronously.

Thanks,
Stefan Kangas

bug#37168: debbugs: Make bug list update asynchronous

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

> When I type:
>
> M-x debbugs-gnu RET ,minor,wishlist RET
>
> It takes a long time to load on my machine, and it freezes my entire
> Emacs session while I wait.  It would be very nice if this operation
> could be made to work asynchronously.

Bug retrieving happens in two phases. The first phase, getting the bug
numbers in question, cannot be performed asynchronously, because it is
just one request to the debbugs server.

The second phase, getting information per bug number, happens already
asynchronously. The debbugs server is requested to return maximum
debbugs-max-hits-per-request per request; several requests are sent in
parallel to the server. Furthermore, debbugs caches the results, so the
next time information for an already known bug number is taken from the
cache.

However, debbugs waits until all parallel requests have been served by
the debbugs server, before it begins to show the tabulated list. This
might be done asynchronously as well. Will check, what's possible.

> Thanks,
> Stefan Kangas

Best regards, Michael.

bug#37168: debbugs: Make bug list update asynchronous

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> Bug retrieving happens in two phases. The first phase, getting the bug
> numbers in question, cannot be performed asynchronously, because it is
> just one request to the debbugs server.

Would url-retrieve work for this?

(url-retrieve URL CALLBACK &optional CBARGS SILENT INHIBIT-COOKIES)

"Retrieve URL asynchronously and call CALLBACK with CBARGS when finished."

> However, debbugs waits until all parallel requests have been served by
> the debbugs server, before it begins to show the tabulated list. This
> might be done asynchronously as well. Will check, what's possible.

Sounds good, thanks.

Best regards,
Stefan Kangas

bug#37168: debbugs: Make bug list update asynchronous

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

>> Bug retrieving happens in two phases. The first phase, getting the bug
>> numbers in question, cannot be performed asynchronously, because it is
>> just one request to the debbugs server.
>
> Would url-retrieve work for this?

Nope. debbugs.el uses the SOAP interface of the debbugs server.

> Best regards,
> Stefan Kangas

Best regards, Michael.

bug#37168: debbugs: Make bug list update asynchronous

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> >> Bug retrieving happens in two phases. The first phase, getting the bug
> >> numbers in question, cannot be performed asynchronously, because it is
> >> just one request to the debbugs server.
> >
> > Would url-retrieve work for this?
>
> Nope. debbugs.el uses the SOAP interface of the debbugs server.

Thanks.  I'm not sure if I'm missing something obvious here, but...
What about soap-invoke-async?

Best regards,
Stefan Kangas

bug#37168: debbugs: Make bug list update asynchronous

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

>> >> Bug retrieving happens in two phases. The first phase, getting the bug
>> >> numbers in question, cannot be performed asynchronously, because it is
>> >> just one request to the debbugs server.
>> >
>> > Would url-retrieve work for this?
>>
>> Nope. debbugs.el uses the SOAP interface of the debbugs server.
>
> Thanks.  I'm not sure if I'm missing something obvious here, but...
> What about soap-invoke-async?

This is performed already. As I wrote, the second request, retrieving
information about (severeal hundred of) bugs, is applied asynchronously,
using `soap-invoke-async'. See `debbugs-get-status'.

> Best regards,
> Stefan Kangas

Best regards, Michael.

bug#37168: debbugs: Make bug list update asynchronous

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> When I type:
>>
>> M-x debbugs-gnu RET ,minor,wishlist RET
>>
>> It takes a long time to load on my machine, and it freezes my entire
>> Emacs session while I wait.  It would be very nice if this operation
>> could be made to work asynchronously.
>
> Bug retrieving happens in two phases. The first phase, getting the bug
> numbers in question, cannot be performed asynchronously, because it is
> just one request to the debbugs server.
>
> The second phase, getting information per bug number, happens already
> asynchronously. The debbugs server is requested to return maximum
> debbugs-max-hits-per-request per request; several requests are sent in
> parallel to the server. Furthermore, debbugs caches the results, so the
> next time information for an already known bug number is taken from the
> cache.
>
> However, debbugs waits until all parallel requests have been served by
> the debbugs server, before it begins to show the tabulated list. This
> might be done asynchronously as well. Will check, what's possible.

Any news regarding this?  If no progress is possible here, perhaps the
bug should be closed.  WDYT?

bug#37168: debbugs: Make bug list update asynchronous

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

>> Bug retrieving happens in two phases. The first phase, getting the bug
>> numbers in question, cannot be performed asynchronously, because it is
>> just one request to the debbugs server.
>>
>> The second phase, getting information per bug number, happens already
>> asynchronously. The debbugs server is requested to return maximum
>> debbugs-max-hits-per-request per request; several requests are sent in
>> parallel to the server. Furthermore, debbugs caches the results, so the
>> next time information for an already known bug number is taken from the
>> cache.
>>
>> However, debbugs waits until all parallel requests have been served by
>> the debbugs server, before it begins to show the tabulated list. This
>> might be done asynchronously as well. Will check, what's possible.
>
> Any news regarding this?  If no progress is possible here, perhaps the
> bug should be closed.  WDYT?

No, nothing happened. And since there aren't no further complaints from
other users, I believe we could leave it as it is. Closing the bug.

Best regards, Michael.

bug#37168: debbugs: Make bug list update asynchronous

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

>>> When I type:
>>>
>>> M-x debbugs-gnu RET ,minor,wishlist RET
>>>
>>> It takes a long time to load on my machine, and it freezes my entire
>>> Emacs session while I wait.  It would be very nice if this operation
>>> could be made to work asynchronously.
>>
>> Bug retrieving happens in two phases. The first phase, getting the bug
>> numbers in question, cannot be performed asynchronously, because it is
>> just one request to the debbugs server.
>>
>> The second phase, getting information per bug number, happens already
>> asynchronously. The debbugs server is requested to return maximum
>> debbugs-max-hits-per-request per request; several requests are sent in
>> parallel to the server. Furthermore, debbugs caches the results, so the
>> next time information for an already known bug number is taken from the
>> cache.
>>
>> However, debbugs waits until all parallel requests have been served by
>> the debbugs server, before it begins to show the tabulated list. This
>> might be done asynchronously as well. Will check, what's possible.
>
> Any news regarding this?  If no progress is possible here, perhaps the
> bug should be closed.  WDYT?

FTR, I've released debbugs 0.41, which uses threads.

Best regards, Michael.