[Kde-pim] My Idea for GSoC Sieve project

[Thomas McGuire]

Hi,

On Tuesday 24 March 2009 04:40:01 Sanja Puvalic wrote:
> Hello Thomas,
> Seems to me I misunderstood a part of the project :)
> I didn't understand we should use the GUI editor at all! I thought it was a
> bunch of conversions and little bit of communication with the mail server
> (if it supports Sieve)
> This makes much more sense now :)

The idea on the wiki page was not written by me. I just think there needs to 
be some GUI editor for the sieve rule, which the wiki page did not talk about. 
Sorry for the confusion.


> 2009/3/24 Thomas McGuire <mcguire at kde.org>
> > On Monday 23 March 2009 21:42:36 Sanja Puvalic wrote:
> > > Hello,
> > > I'm Sanja Puvalic, student from Belgrade University, Faculty of
> > > Mathematics.
> > >
> > > I have an idea how I would work on project "import/export for filtering
> > > rules in Sieve format in KMail"
> > > I already tried getting some feedback on the developers mailing list,
> > > and got no replies. I hope I'll be luckier here :)
> > > My idea in brief:
> > >
> > > - study the k-mail filter format
> > >
> > > - make a small parser using lex and yacc to convert to sieve format
> > > this in convinient because it's more flexible and the replacement can
> > > be done more automaticly - and we don't have to spend a lot of time
> > > writing code for parsing various commands in c++ - just try to fit the
> > > Kmail mail rule to the Kmail mail filters grammar which we can write,
> > > and
> >
> > automaticly
> >
> > > generate a Sieve command
> > >
> > > - check if the server supports sieve
> > >     - if it does, upload to server
> > >     - if not, make exporting easy
> > >
> > > - exporting:
> > >
> > > if we can afford to make the export file readable (if we don't care
> > > about security and privacy issues), the mail rule export format could
> > > be very similar to a sieve command itself
> > > if not, we could do some simplest encrypting by, for example, just
> >
> > xor-ing
> >
> > > the file to "sieve-is-cool", and then xor back when importing to kmail.
> > >
> > > Let me know what you think of my idea, am I on the right track? :)
> >
> > I think using the existing KMail GUI filter editor for editing Sieve
> > filter rules should be the goal of the project. Right now, there is the
> > menu entry Settings->Manage Sieve Scripts. In this dialog, you should be
> > able to use a GUI editor similar to the on in Settings->Configure
> > Filters, by reusing the classes used there.
> >
> > That means:
> > - The GUI editor should be able to export to native sieve
> > - KMail should be able to read sieve and set the GUI editor to the rules
> >  that have been read
> > - If the current GUI editor doesn't support all Sieve rules, add support
> > for
> >  the missing rules
>
> Now I have an idea how this can be done, and I think it won't be a big
> problem since we already have the interface in Settings->Configure Filters
> as a guideline.
>
> > I don't understand what you mean by "make a small parser using lex and
> > yacc to
> > convert to sieve format". That sounds like you want to parse the KMail
> > config
> > file format, but we already have a nice in-memory representation of that,
> > which we can use. Shouldn't it be the other way around, and KMail needs
> > to parse the sieve scripts, or am I missing something here?
>
> I misunderstood something, yes. So, if I understand well now, you want to
> transfer the existing KMail filters into sieve format, so you can even
> store them later in sieve format? So, practically, you want to stop using
> KMail filter formats at all, and store everything in sieve format? At first
> I understood that we should just try to talk to server in sieve language,
> and export in sieve format.
> If we want to transfer to sieve completely, than yes, we should put the
> nice in-memory representation in sieve format. But why would we need to
> implement the parsing of the sieve scripts in KMail? Maybe I'm (again)
> misunderstanding the sentence "KMail already has support for talking to
> Sieve enabled servers" . Doesn't this mean this is already implemented?
>
> I'm confused :)

If possible, we should store the filters on the server only, but still allow 
storing the filters (as a sieve script) on disk if the server is currently 
offline and the user needs to save the filter rules.

The sieve parser would be needed because the script on the server might be 
modified by something else than KMail, and then you want that the updated 
rules are displayed in the filtering GUI.

Regards,
Thomas




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090324/634554c3/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/