[ingo] Fwd: interesting in ingo development
Mike Cochrane
mike at graftonhall.co.nz
Sun Dec 8 05:33:10 2002
> ----- Message from meyer-jordan@t-online.de ---------
>
> > > 1. I've looked around in ingo code: importing (better: displaying) of
> > > existing rules/sieve
> > > scripts isn't implementet yet? Correct?
> > > (On my test installation the 'Rules' list stays empty, as well.)
> >
> > As far as rules that are allready on the server, this is not planned nor
> very
> > possible actually.
>
> So perhaps an important playground for me. (But a very difficulty one -
> unless,
> except the PHP sieve tools already have rule parsing functions inclunded. But
> I
> don't think so - however I haven't looked for that until now.)
>
> I like a solution wich is controlable by different tools/frontends at the
> same
> time. That's my fundamental impulse to look for processing existing rules.
> (But
> even Mulberry 3.0.0 [Windows] isn't able to handle server based scripts
> correctly.)
>
Just a bit more info on this one.... the PEAR sieve class has no rule parsing..
it's just a class to connect to a timsieved server.
Ingo is written without any concept of else's or nested blocks. So if on you
server you had a script like this:
if (a) {
x;
} elsif (b) {
y;
} else {
z;
}
if {c) {
l;
} else {
m;
}
the way this would be stored and outputed by ingo is:
if (allof(a, c)) {
x;
l;
stop;
}
if (allof(a, !c) {
x;
m;
stop;
}
if (allof(!a, b, c)) {
y;
l;
stop;
}
if (allof(!a, b, !c)) {
y;
m;
stop;
}
And it goes on for a couple more.
That was my problem with the whole idea, and then consider what happens if you
have nested if's....
If someone can come up with a solution to this i would be very interested.
- Mike :-)
More information about the ingo
mailing list