Re: Maybe too strict check for frontend/backend name conflicts

Hi Krzysztof !

On Fri, Nov 02, 2007 at 03:09:01AM +0100, Krzysztof Oledzki wrote:
>
>
> On Fri, 2 Nov 2007, Krzysztof Oledzki wrote:
>
> <CUT>
>
> >>I will see if I find a way to do that test very easily, but I think I
> >>have an idea.
> >
> >Actually, I believe one of my patches, I have developed for some time, can
> >be very easily adopted to do this. If you can wait a day or two I can post
> >finished version with this additional improvement.
>
> Here it is, much faster than previously announced. ;)

I'm amazed :-)

> Below you can find
> the stripped version of mentioned patch, with unready parts removed, but
> extended to do what I hope you had expected. RFC quality so not for commit
> this time.
>
> This patch:
> - adds proxy_mode_str() similar to proxy_type_str()
> - adds a generic findproxy function used with
> default_backend/senbe/use_backed
> - rewrite default_backend/senbe/use_backed to use introduced findproxy()
> - relaxes duplicated proxy check

I like it. It makes both the parsing and the checks cleaner. It reminds me that we have to change the capabilities displaying from "%X" to "%s" with a call to proxy_type_str(). When I first saw the error messages, I got "conflicting names for proxy capabilities 7/7" or something like this, and eventhough I know what it means, I cannot expect normal users to be aware of the internals.

Also, you might have noticed that I'm trying to de-centralize the parsing to various files, in the hope that later we'll be able to easily load modules which add keywords. Since you're adding new functions such as findproxy, see if you can put them in proxy.c. Take a look at how I managed to pass the error messages in return from dumpstats.c, or even in backend.c (backend_parse_balance, in latest master-git). I've not found the perfect interface to all parsing functions yet, but I'm sure we'll soon have something standard for use with all sub-components.

It will also greatly improve error messages report since each level can complete the message with more information, and the last level can put the line number which we don't always have. I'll have to update ACLs to use the same interface so that we can at last get human-readable error messages for incorrectly written ACLs.

Best regards,
Willy Received on 2007/11/02 06:25