> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Champ Clark III [Softwink] > Sent: Friday, October 08, 2010 5:05 PM > To: rsyslog-users > Subject: Re: [rsyslog] liblognorm > > > Starting this morning I have begun to wade in-depth through a pile of > CEE > > docs (the upcoming standard). We may need to make some format > adjustments, > > but I'd like to stick with somewhat as simple as possible to write > for the > > samples. > > Do you have a link to the CEE documentation for the upcoming > standard? I'd be interested in taking a look.
Unfortunately the public site currently has only a limited selection. I need to check if I can share some of the current drafts. The Dictionary and Taxonmy stuff is most interesting. Anyhow, the public site definitely helps getting the idea: http://cee.mitre.org/ > > > Will the log formats, that is, what to look for, > > > be in a seperate text file that can be updated? As you mention in > the > > > blog post, "much like a virus scanner". > > > > Actually, at this point nothing is really finalized. For the initial > effort, > > it will definitely be a text file. But in the long term I can also > envision > > that we should be able to pull it e.g. from web servers or load > multiple > > files, or... actually something that should be configurable. > > IMHO, I think leaving it a text file would be best. Let some > other process (wget, whatever) pull the definitions. Or let the user > do it manually. Again, IMHO, I think having the actual library > pull > the definitions might be outside of the scope. That sounds good. The only thing that I am pretty sure about is that - at some stage - we must support *multiple* files. That is because I envision that some may be pulled from a global repository but some local-only may also exist. I think it is easier to manage those if they can be kept in different files. > > > > > If that is the case, will programs that use liblognorm pull that > into > > > an array first, and let liblognorm do it's work? Or will this > file > > > have to be repeatedly referenced? > > > > In the long term I think it makes sense to provide a way to stuff > samples in > > via either a dedicated API OR (and?) have them loaded based on a > config file. > > The latter is what I have on my mind for the first step. > > Sounds great. > > > > I'd love to help out in this, be it code wise and/or log examples. > > > > Any help is deeply appreciated and these questions already help! Log > samples > > and trying out the library, once it materializes, would be a very > very great > > aid. > > > > I will write a couple of more blog posts with more details, and > everything is > > really open for change now. It would also be very useful if you could > spread > > the news. An as wide audience as possible would be very good. > > Sounds great as well. I know on this end of the wire, you've > already got one beta tester :) I'm really itching to try it out, but > I > know it's not even near that point! I'll be more than happy to help > out where I can (code, log examples, etc). Looks like we are in business ;) I need to digest what I have read today, but it looks like I will begin to create some skeleton code next week, starting with the build system and followed by some important definitions (e.g. for tags, fields and so on). Feedback on the organization of this material is also appreciated. I'll populate the public git as soon as I have some lines of code ;) Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
