On Thu, Jun 17, 2010 at 8:49 AM, Rainer Gerhards <[email protected]> wrote: >> <input name=inp10515 type=imtcp><params>listen 10515; ruleset >> remote10515</params></input> > > > This was something we discussed, and kind of my favorite. I got convinced by > the following arguments > > a) Apache uses a single parameter, and it always is the name of the object > described > b) this becomes ugly if there are more than a handful of modifiers (and there > sometimes are) > > I'd appreciate feedback on these arguments. Note that the overall idea of > staying close to Apache is that folks already know that format -- and it > seems to be received well.
I don't think the Apache argument holds weight - its being used in a generic look-and-feel sense as opposed to yanking its actual config parser. If the modifiers are static - ie, "type, name, use" can be used everywhere - that would solve the concern about adding more and more modifiers. Personally I'd say having "name=" instead of name being implicit would be nice as a minimum. This is a personal style thing though. >> I think it comes down to this (i'd bold it if this wasn't plain text): >> We should be able to easily understand what is being declared against >> what is being applied, and I think this initial mock-up can be >> confusing. > > Can you elaborate a little bit more -- I simply do not fully understand the > sentence (probably a non-native speaker issue). I've been convinced on the declare wherever argument by yourself and RB. But as a clarification on this point: I think it should be easy to tell what is a declaration and what is an application. For example, if I define an action queue in the global scope, its a declaration because i MUST reference that declaration in order for it to do anything. That's a declaration. Defining an action queue in a ruleset appears to be an application - it does not require later reference - and thus isn't a declaration. I think that when looking at the config, it should be clear what is a declaration and what is an application. Does that explain it better? -Aaron _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
