[Kde-pim] My Idea for GSoC Sieve project

[Sanja Puvalic]

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



2009/3/24 Thomas McGuire <mcguire at kde.org>

> Hi Sanja,
>
> 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 :)



>
> About exporting: This I also don't fully understand. Can't we simply export
> to
> the sieve format?


Yes, of course! If we don't have security issues.

We need to be able to import sieve anyway, for the GUI
> editor. And I think false security like xor'ing the file is futile, leave
> that
> part out, there is no need for it.


Of course, that could only stop a very lazy and naive user from reading
someone's filters, nothing more than that.


>
>
> Regards,
> Thomas
>


Thanks for replying, Thomas. I'm sorry for misunderstanding :)

All best,
Sanja


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