Re: Patch: fix the progress information when refreshing an imap folder
- From: "Martin Bonnin" <martinbonnin gmail com>
- To: "Sergio Villar Senin" <svillar igalia com>
- Cc: tinymail-devel-list <tinymail-devel-list gnome org>
- Subject: Re: Patch: fix the progress information when refreshing an imap folder
- Date: Thu, 20 Nov 2008 19:57:43 +0100
Hello Sergio,
Ignore my last email, I made a mistake with my gmail account :(
2008/11/20 Martin Bonnin <martinbonnin gmail com>:
> Hello Sergio,
>
>
> 2008/11/20 Sergio Villar Senin <svillar igalia com>:
>> Martin Bonnin escribiu:
>>> Of course I do this in the application code :)
>>>
>>>> And that's all. With this filter you'll only get progress information
>>>> about the folder refresh and not about the other operations.
>>>
>>> See the 2 gdb backtraces below. The first one is the"bad" progress.
>>> The second one is "good". Both have TNY_FOLDER_STATUS_CODE_REFRESH as
>>> the status code but the first one is called from
>>> camel_stream_buffer_read_opp() with inconsistent values.
>>
>> OK, I got your point. This is indeed an issue in tinymail that we need
>> to fix, and it's the fact that an operation like refresh, provides
>> different types of information because it's actually a composition of
>> some others, like opening summary, update summary etc...
>>
>> Thing is that almost everything that you could do in Camel is like that,
>> so you'll be only "fixing" particular situations all the time. And
>> thinking about tinymail POV, as a library in this case, I'm pro offering
>> as much as info as possible to the apps. Applications should filter it
>> to present it to the user. You could always use the "what" parameter, I
>> know it's ugly to compare strings, but I think it's better than fixing
>> specific situations. What do you think?
I kind of agree with you. But in this specific case, checking the
"what" parameter is still not enough because it is the same in both
cases.
Problem is that the the "bad" progress is deep inside camel operation
and I'm not sure to what it refers.
Maybe we could just wrap the camel_imap_command_response() between
calls to camel_operation_start() and camel_operation_end() but this
is more invasive as a change...
--
Martin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]