Hello!
On Fri, 18 Oct 2002, Nico Erfurth wrote:
> Alexander V Alekseev wrote:
>
> This is my last reply to you, because this discussion is pointless.
Ok. So, I summarise: i faced undocumented bug (you call it
a feature). You do not want either to fix it, or to document. You're
wrong.
> > like this: operation1{operation2{something}} and need first to
> > expand operation1 using "operation2{something}" as argument, and only
> > after that you need to expand "operation2{something}" into new string.
>
> This isn't how exim works, all arguments will be expanded before used,
> example
There is no way to change it's behaviour in some 'standard' way.
You do not need it. It doesn't mean, that it shoudn't be.
> ${if eq {$local_part}{${lc:$local_part}} {yes} {no}}
>
> This will work, the rgument wills be expanded before used, but to come
> back to your example:
>
> This would be the correct way for exim, for what you want:
>
> ${expand:${operation1{\N${operation2{something}}\N}}}
This means, that operation1 thus have a quite different
syntaxis, than another (which you like) operations. So, you'll have many
ways of making one thing in different constructs. The example is (was?)
discussed in another thread for HMAC patch about using ':' as arguments
delimiter. I think it's wrong.
> > I think, you can invent current example yourself.
> > But I can explain, why I need this feature: I tried to speedup
> > lookup process to any lookup type you want. How can we do it? The only
> > way of doing it (without modifying all lookup types) is to wrap
> > cashed lookups in a new lookup types. For example, if you have (just
> > from spec.txt):
> > ################################################
> > data = ${lookup mysql{ALIAS_QUERY}}
> > ################################################
> > so I rewrite it as follows:
> > ################################################
> > data = ${lookup sharedcashe {lookup mysql{ALIAS_QUERY}} }
> > ################################################
> > and we first look in cashe, using string "lookup mysql{ALIAS_QUERY}}" as
> > key, and if nothing found, add '${' before and '}' after the lookup
> > key, and expand the string once more.
> > If you always escape your {} , nothing bad will happen. But it's
> > too ugly to change {} to anything alse in case shown.
>
> Wrap it in \N TEXT \N, this is what this was made for.
You mean, I cannot use exim's syntaxis inside my operations.
This implies ugly syntaxis. This implies more time on converting queries.
You don't wand to understand it. I think that's wrong.
> > But there is no idea in documentation, that unescaped {} should
> > sometimes work! They should never work, or be clearly documented!
>
> Why not?
> Write it 100 times
> This is not C
> This is not C
> .....
I know, that's not C . But it'll not become documented. Once
more: it should be documented or fixed!
> > You're right. Everyone escapes them. So, what do you worry about?
>
> Your patch WILL break stuff, you are thinking in terms of a complete
> script parser, but exim's expansion language is made for speed (Philip
> will decline this (as usual), but it's true ;) ), the parser just cares
> about things he NEED to know at this moment, not more, not less.
I've seen the parser. I have questions on it's design. Now i
would say nothing. Just not to fire a new flame.
> You got me wrong, Exim acts like as it should, it just interferes with
> the chars it needs at THIS moment, this is the concept, your patch
> destroys this.
You mean, you like this exim behaviour. You don't use it, you haven't
heared of anyone using it, but it should be that way. Another men said,
they do not use this behaviour, and will have no trouble either applying
the patch, or not. This sounds more realistic.
> > BTW, I did that just to speedup overal speed. (Though
> > exim's speed is quite discussible. On my P4 1.8 / 256M I see only
> > about 100 messages per second enqueued, and about 30 messaged per second
> > relayed. On such configuration, CGP enqueues more 1000 messages per second,
> > and relays about 300. ;-(( I used default config, supplied with exim,
> > but changed all lookup to MYSQL. Using default lsearch fails to
>
> So maybe you should think about changing to something else
> (cdb,dbm,tdb,ldap,whatever). Maybe you should read spec.txt for the
> usual performance-hints, and learn about address_data etc.
> exim -d helkps to find bottlenecks too, be creative, not destructive.
Did you try it? I did. I really mean, what I say. Does anyone have
another performance count?
> > extremely low speed. The main trouble is fork(), and reinitialisation.
> > But I don't think, it's really possibly to make exim threaded in a
> > moderate period of time. )
>
> I would not want exim to be threaded, exim avoids to synchronize as much
> as possible, and that's good.
Exim relies on outer syncronization. It's easy, but very
time-consuming.
> > You pointed out, that everyone escapes {}. That's right. Why do
> > you think then, such undocumented bug should be supported? For someone,
> > who don't read the documentation?
>
> Why it should be a bug?
> If exim would use perl-,ruby-,python- or *-like expressions for the
> configuration i would say "ok, it MUST be like in the real language",
> but this is exim.
A bug is that it's undocumented. Document, or fix!
Bye. Alex.
