2015-04-28 18:57 GMT+02:00 David Lang <[email protected]>: > On Tue, 28 Apr 2015, Tait Clarridge wrote: > >> On Tue, Apr 28, 2015 at 8:24 AM, Rainer Gerhards >> <[email protected]> wrote: >>> >>> Hi all, >>> >>> I receive a new parser contribution, please see here: >>> >>> https://github.com/rsyslog/liblognorm/pull/44 >>> >>> All looks great, except that the name for the new parser is "string", >>> what I consider overly generic. Probably "bash-like-string" would be >>> better, but still not perfect IMHO. >>> >>> Are there any suggestions here in the group? >>> >>> Thanks, >>> Rainer >> >> >> >> Perhaps "posix-string" or "safe-string"? > > > is there a posix spec we can point to if we use posix-string? > > It's not really any safer than other sting types > > I see three paths we can go down > > 1. create a new type, escaped-string and have flags to be able to disable > some of the escaping, specify if the outer quotes should be included or not, > and possibly specify some additional escape decoding (I'd like an option to > recover the rsyslog #xxx control characters for example) > > 2. replace one of the existing types, adding flags to enable these features > > 3. replace one of the existng types, enabling new features by default and > adding flags to disable them. This has the potential to break some existing > configs, but in the vast majority of cases it will not. > > In any case, I think that the other string types should be redefined to be > this new type with specific options (i.e. effectively turn them into macros) > to eliminate code duplication.
I agree on that, but would like to do that later in the process when I am rewriting that part of the lib in any case. Remember that I want to introduce a new, better rule description language and that would much better be suited to provide such options and so on. Right now, I just want to add all parsers that come up and are considered useful - so it's currently more or less a doc problem. > > > The big problem with #1 is that we are getting to have more and more > parsers, how is someone supposed to know which one to use and remember the > right name for it. I think we can address this by a better structured doc. We need this for v2 of liblognorm in any way, because there still will be a large number of parser. > > requiring flags to be enable the functionality is slightly better, but the > question is if these are things that should be enabled unless they cause > grief, or disabled unless absolutly required. > > I think that using \ escaped characters in strings is a pretty common thing > to do, so I think it's very reasonable to have this enabled by default. Again, I agree on the overall idea, but really just looking for a small tactical step in the final phase of v1 of liblognorm. I would just like to use a somewhat descriptive name for the new parser. Rainer > > David Lang > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
