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

Hi Krzysztof,

Sorry for the delay, you know what it is...

On Sun, Nov 04, 2007 at 04:21:52AM +0100, Krzysztof Oledzki wrote:
>
>
> On Sat, 3 Nov 2007, Willy Tarreau wrote:
>
> >On Sat, Nov 03, 2007 at 02:47:19AM +0100, Krzysztof Oledzki wrote:
> >>>>How about adding a global "char errstr[BUFSIZE]"? Each function can then
> >>>>easily return a appropriate error message. No need to pass additional
> >>>>buffers and lengths.
> >>>
> >>>That's what I thought about first, then I realized that it would not be
> >>>convenient for intermediate functions to prefix the error messages with
> >>>their part of context. For instance, such a message could be completed
> >>>by 4 different levels :
> >>>
> >>>"Proxy xxx: rule yyy: acl zzz requires HTTP mode"
> >>> <--- level 4 ---->
> >>> <------- level 3 -------->
> >>> <------------ level 2 ------------->
> >>><------------------ level 1 ------------------>
> >>>
> >>>So in certain circumstances, the error message will be on the caller's
> >>>stack.
> >>
> >>Oh, indeed. But this still can be solved without passing
> >>additional references. Attached example code that produces:
> >>
> >>"Proxy xxx: rule yyy: acl zzz requires HTTP mode"
> >
> >Your example does not solve every case. It assumes that the messages are
> >completed from deeper to outer level only. But in many cases (mainly for
> >outer levels), we'd prefer to pre-initialize the error prefix before
> >calling the inner functions, in order to avoid having to do this in every
> >if/else statement.
>
> Right...
>
> >I'm still thinking about this, but I believe that what we need is a stack
> >or text fragments that can be fed by all the functions. We would then only
> >pass to each function the stack level (most always 'level+1'). We would
> >then
> >have two functions:
> > - init_error_stack(int level, char *msg) : clears upper stack and inserts
> > msg
> > - set_error_msg(int level, char *msg) : inserts msg without clearing stack
>
> OK. How about the new attachment? It generates:

I'm still not fond of it, because it does not look very intuitive to use, and I generally don't like it when code does "magic" things such as displaying a text I seem to have no control of.

> Proxy xxx: rule yyy: acl zzz requires HTTP mode
> Proxy xxx: acl zzz requires HTTP mode
>
> >We would also need a collapse function to merge many levels into one, which
> >is handy when you need to merge the message inside another one :
> > - collapse_error_levels(int level)
>
> Hm, to merge everything starting from the "level"? This should be
> also possible, but in which situation it may be useful?

In several cases. Sometimes the error may be build while parsing the config from a CLI, and the error would be stuffed into a socket buffer. Sometimes, an error might be detected at run time (eg: a layer7 ACL being called on a layer4 session), and we might like to send it into the logs. In debug mode, maybe we'd like to report many information about what is happening, and in this case we might decide to report debug info as errors along all the calls. Those are just ideas which come to my mind of course, they are not a roadmap :-)

Best regards,
Willy Received on 2007/11/14 08:39