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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
