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

[Not Zed <notzed ximian com>]

On Thu, 2004-03-11 at 08:35 +0100, Radek Doulík wrote:

> 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.

But it can just as easily be done only once ...

> > > 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?

Because it breaks the abstraction on vfolders more than its already
broken, and its only required for a work-around solution.

> > 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

It should be pretty obvious to see from the code once you get in there.
Its essentially but not quite exactly the same way imap filtering works.
And there's only a couple of places you need to add any code.  And you
can get rid of all the stuff in mail-ops.c

I wont be on tonight, jeff should be able to help if required, but it
shouldn't be needed.

 Michael