[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