[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Architectural problems shown by the anti spam wizard
From:       Don Sanders <sanders () kde ! org>
Date:       2004-01-30 1:33:20
Message-ID: 200401301133.20610.sanders () kde ! org
[Download RAW message or body]

On Thursday 29 January 2004 17:33, Andreas Gungl wrote:
> Don Sanders wrote:
> > Hi Andreas,
> >
> > On Thursday 29 January 2004 05:45, Andreas Gungl wrote:
> >>Hi,
> >>
> >>for those who are interested I want to describe some problems I
> >>came over while I worked on some details for the anti spam
> >> wizard.
> >
> > I'll try to answer your questions as best I can. But I'm having
> > difficulty because I don't understand the intended workflow for
> > setting up the anti-spam stuff you have been working on.
> >
> > Don't get me wrong it's a critical feature in my opinion, but I'm
> > lacking clarity on how exactly it is meant to work from the end
> > users point of view. Is it intended to work like the Mozilla
> > ant-spam stuff? (I haven't used that either, but I see lots of
> > people saying good things about it).
> >
> > I don't understand what value the new spam/ham statuses have for
> > instance.
>
> I'll try to explain it in short here:
> The main problem is that KMail doesn't have built in spam filtering
> - in contradiction to Mozilla. Installing Mozilla gives you all you
> need, so you can rely on your own. KMail wants to cooperate with
> existing anti spam tools. The "average user" (whoever it is) has
> two problems IMO. She would have to check what tools are installed
> (installation could be prepared by the distributors) and then
> (perhaps more difficult) she would have to define filter rules to
> let KMail properly cooperate with the tools.
>
> The wizard tries to find installed tools. Then it allows to let
> create filters to use the tools to detect spam mails (basically by
> piping through the tools) and to handle spam messages e.g. by
> moving to trash (by identifying related headers like X-SpamFlag).
> Having bayesian spam tools, you need to learn them. So the wizard
> can create rules to let the tools learn ham and spam messages.
> The creation of the tools is done based on information in a config
> file (kmail.antispamrc, see CVS), so new tools can get added
> without changing the code.

Ok. I guess it makes sense for the user to have to explicitly activate 
spam filtering before it is used so a wizard that appears when the 
user first tries to classify spam or something makes sense.

> Detection and handling rules are applied on incoming messages and
> on manual filtering. Classification (learning) is done using ad-hoc
> filters.

To me ad-hoc filters refers to filters listed in the filter 
configuration dialog with "Add this filter to the Apply Filter 
Actions menu' chechbox ticked.

I'm not sure whether it is a good idea to involve those with spam 
filters. 

An alternative would be to create two KActions 'Classify as spam', 
'Classify as ham' in kmmainwidget, create two corresponding slots* 
KMMainWidget::slotClassifyAsSpam, KMMainWidget::slotClassifyAsHam, 
and in the kernel create two KMFilters one to mark as spam, one to 
mark as spam. These KMFilters would be deleted and replaced by new 
KMFilters if spam tool options were changed (via the wizard or a 
configuration dialog or whatever).

To make sure the KMFilters are applied to incoming messages the 
KMFilterMgr (which should eventually be obsolete) and the 
ActionScheduler (which is the replacement) could be updated.

> >>Current situation:
> >>
> >>   The concept of ad-hoc filters allows dynamic plugging of
> >> marked filters into the KMail menu with a slightly modified menu
> >> item name (derived from the filter name) plus an icon (both
> >> defined in the filter dialog). When the configuration has
> >> changed, all items get removed from the submenu and each marked
> >> ad-hoc filter gets added then into a "clean" submenu.
> >
> > Are we talking about KMMainWidget::initializeFilterActions()
> > here?
>
> Yes. It comes down to this.
>
> > Yes in my opinion there is an implementation weakness here,
> > rather than deleting the old KActions (mFilterActions.clear())
> > existing KActions should be reused where possible. This may be
> > possible by using the normalizedName.local8Bit() which is passed
> > into the KAction constructor and hence is the QObject::name() for
> > that KAction.
> >
> > At least I was experiencing a problem due to this clearing of
> > existing KActions, and this is the solution I was thinking of to
> > fix it. Are thinking about the same thing here?
>
> Yes, but see below.
>
> >>You can now use the toolbar editor to include some of the
> >> (dynamic) menu items (actually actions) into the toolbar. This
> >> will work fine as long as you don't remove the menu items by
> >> e.g. deleting or renaming the filters. In this case the action
> >> entry in the XMLGUI config file will stay but the toolbar icon
> >> is no longer shown because the corresponding action can't get
> >> found.
> >>Here the XMLGUI definition and the filters get out of sync which
> >>can be a source for problems later on.
> >
> > I wonder what these 'problems later on' are. I guess they are
> > important as you mention them?
>
> You may end up with some (many?) unused resp. invalid action
> entries for the toolbar in the XMLGUI ressource file. As soon as
> you have any new action named like such an entry, a toolbar button
> will show up even if you never intended to create one.

If each KMMainWidget has two fixed KActions for classifying as 
spam/ham then would this problem still exist?

I'm not sure I understand, this problem is due to the QObject name of 
the spam classification KActions being variable, correct?

> >>   The wizard plugs the action into the toolbar and to make the
> >>change persistent it modifies the XMLGUI file. This is done by
> >>manual manipulation of the XMLGUI file, currently there is no API
> >>which would support automatic write back of the current config by
> >>the toolbar itself. Of course the user will face the sync
> >> problems described above sooner or later.
> >
> > Not completely sure I understand the sync problems.
>
> The toolbar does not change it's XMLGUI config file when you plug
> an ad-hoc filter based action into it. A button would show up after
> you have plugged the action, but after a restart the button is lost
> if you don't replug it again.
> The wizard tries to eliminate the restart problem by additionally
> adding the actions to the ressource file.

So again this is due to the QObject name of the spam classification 
KActions being variable?

> >>Another problem might be based on
> >>translation (i18n) issues when e.g. the user switches the
> >> language, but I have no concrete scenario for this, it's just a
> >> guess.
> >
> > If you look at the KAction constructor in
> > initializeFilterActions() the QObject::name() is not i18n()'d so
> > this should be invariant in the case of the user switching the
> > language.
>
> The action names are based on the filter's name.

So that would seem to be the problem, the action names should be fixed 
rather than dependant on the filter's name.

> If the wizard 
> creates a filter "mark as spam" it should be "als Spam markieren"
> in German. When I change the filter's name manually, the action for
> the ad-hoc filter menu item get's a new name, but the entry in the
> XMLGUI ressource file doesn't get changed. They don't belong
> together anymore!!!

> >>Possible solution:
> >>
> >>   We might add an option to the filter definition which depends
> >> on the filter being marked as ad-hoc so that then it can
> >> additionally marked as "include in toolbar". This would support
> >> the idea of dynamic actions based on the current filter
> >> configuration. It also would eliminate the sync problem between
> >> filters and XMLGUI ressource.
> >
> > Why would if eliminate the sync problems, it seems I'm missing
> > something or not following clearly.
> >
> >>A drawback is that the user can't make persistent changes to the
> >>position of these actions in the toolbar,
> >
> > Why?
>
> To let the position change be persistent, you would have to write
> it into the XMLGUI ressource file. Then you have the problems
> described above. You might store it somewhere else, then you get
> problems when the user manipulates the toolbar manually.
>
> >>which is really no good
> >>UI design. A special filter toolbar is bloat, IMO.
> >>
> >>
> >>I've thought about the possibility to have some predefined
> >> default actions which might be disabled or hidden as long as no
> >> action provider is bound to them.
> >
> > What are you referring to by action provider? A KAction, based on
> > a filter in the filter dialog?
>
> See below.
>
> >>Let's say that we have a default action "mark as spam". The
> >>appropriate filter should register to this action making the
> >> action active. After that the user may configure the action
> >> regarding the toolbar position. My conclusion was that this (up
> >> to now) a very special case. It's more complex to implement than
> >> the solution above. And I still have no clear picture about what
> >> would this imply for other parts of KMail.
> >
> > I think default actions make sense.
>
> The mark spam action would be by default in KMail.

Good.

> Then, there 
> might be some code (the provider) which registers to it by saying,
> hey I want to be called when the mark spam action is triggered. It
> can be made inside the KMail code base e.g. by letting the user
> associate a filter with an action (oh, I don't really want this) or
> by even having a dcop interface for external plugins.

So I think it makes sense to have a couple KMFilters in the KMKernel, 
or create a new SpamClassification class that contains a couple of 
KMFilters and have a reference to that in KMKernel.

*The slotClassifyAsSpam, and slotClassifyAsHam could also be methods 
of this SpamClassification class, or whatever.

> >>I would like to know what is your opinion about this problem?
> >> What are your (the core developers') plans regarding changes to
> >> the filter system in the near future? How do this ad-hoc filters
> >> fit into a concept of using sieve to support filtering on the
> >> server side? Does anybody has plans for a plugin system and how
> >> could it deal with the problem described above?
> >
> > Unfortunately I don't understand the proposed anti spam wizard
> > well to understand what 'this problem' is well enough to be able
> > to answer these questions.
> >
> > I should be on #kontact till about at least GMT 9:00am if you
> > want to discuss things on irc.
> >
> > Don.
>
> Sorry, I'm not at home so I've no IRC access. I hope I've explained
> the open issues detailed enough.

Ok. Discussing architecture via email is difficult in my experience, 
hopefully we've made some progress.

Don.
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]