Re: [Evolution-hackers] mark junk/not junk problem

[Radek Doulík <rodo ximian com>]

On Thu, 2004-03-11 at 09:37 +0800, Not Zed wrote:

> This solution isn't any good, sorry.
> 
> On Wed, 2004-03-10 at 17:31 +0100, Radek Doulík wrote:
> 
> > Hi Michael,
> > 
> > I have thought more about mark junk/not junk problem and I think this
> > solution might work well:
> > 
> > UI thread:
> >       * put real folder reference and msg's uid (in that folder) to
> >         array we pass to learn_junk thread
> 
> You can't get the real folder references.

I think it's possible the same way as in vee_folder_set_message_flags.

> >       * set/reset junk+learn flags
> >       * e_thread_put learn_junk thread
> > 
> > learn_junk_thread:
> >       * get CamelMimeMessage with uid from folder we get
> >       * if we get the message and it has the learn flag then reset the
> >         flag and call report
> 
> This leads to the same inconsisent, and quite frankly terribly difficult
> to use api, that already exists.
> 
> You have to remember to explictly send messages to the plugin learner,
> as well as setting the junk bit.  Essentially the junk bit is just for
> the ui, and a waste of time having it in the backend.

dunno if you understand me here. learn_junk thread resets only the learn
bit, not the junk one

> > folder sync:
> >       * check all messages in folder summary and for those with learn
> >         flag reset the flag and call report
> >       * remove learn flag from them
> > 
> > Like this it will not delay the learning until the folder sync time. In
> > case the learn junk thread will not get the msg from folder, it will
> > ignore it and it will be handled in folder sync. (later, or sooner).
> 
> Why do things twice?  Its completely pointless.

in case the message gets copied meanwhile. it may just call the same
method, so it could be done at the same place. I see it's not yet
optimal, but IMO better than current state.

> > I think it should be OK to pass the folder reference to the learn_thread
> > as we pass one folder reference already. It might need some additional
> > API in camel-vee-folder to get the orig folder uid (like
> > camel_message_info_uid(mi) + 8).
> 
> Yep, but its not going to be added, sorry.

why would it be a problem?

> Anyway I had a thought while i couldn't get to sleep last night, which
> should hopefully be acceptable to you, because it:
>  - simplifies the api to simply setting or unsetting bits on the
> messageinfo
>  - applies the learner asynchronously, but as soon as possible

that sounds good

> In camel-folder.c:folder_changed
>  - add another bit to camelmessageinfo for 'learned' stuff,
>  - add a check for changed uid's that change the junk status
>  - add these uid's to the existing filter_folder structure and fire off
> the existing filter folder code.  you probably need 2 lists, one for
> stuff to mark as junk and one for stuff to mark as not junk
> In camel-folder.c:filter_filter
>  - if there are junk messages, set/unset the junk status
>  - if there is anything to filter, filter it
> In camel-folder.c:camel_folder_set_message_flags
>  - if you're setting or unsetting the junk status, and the learned bit
> isn't being set too, then clear the learned bit.

I don't understand parts of it so I will look at the code and ask you on
irc. I didn't sleep very well either. It's a pity we didn't solve it
yesterday. I should have probably noticed that it was too early/late for
you, but I was quite disappointed from the end of the conversation :(

cheers
Radek