|We don't bite newbies here... much|
Re^2: RFC Win32::Event2Log ..gimme back my logfilesby Discipulus (Monsignor)
|on Feb 02, 2018 at 11:35 UTC||Need Help??|
Many thanks Anonymous Monk for your review, full of good links and suggestions!
let me comment back..
> write a few dozen user programs ... concentrate on verbs/actions the user would perform ..
I'm already doing this: I need to use my module already so I'm testing on various scenarios.
> Ask yourself why would anyone use your module instead of EventLog
Well I'm confident enough with my lure: it abstract all the boring part of using Win32::EventLog as counting events, get them back in the right way (consider the module has a bit weird interface, not easy to use under strict and warnings, populating globals variables like in my $base; $handle->GetOldest($base) )
More: my engine tracks and logs last numbers read for each registry, so if you restart the program you just read newer events: this is achieved via the lastreadfile option in the engine contruction.
It also automatically open and close your destination logfiles with an autoflushed handle: this is the only way I found to have no buffering done by the OS.
Finally providing a callback in the rule creation lets the final user to really do what they want. Rethinking about this probably it's worth to be redisigned: I now constrain the rule to have a destination logfile associated and optionally a format callback.
Perhaps it will be better to let logfile optional if a callback it's specified: so a better name will be action or callback instead of format This can lead to an extreme flexibility: no more the output to a logfile but, for example: if an event is found write a mail and restart a service.
The above abstraction will affect the name too: Win32::EventTrigger or Win32::Event::Engine ?
Links provided are useful (apart from the la-berre one unavailable..) and you are probably the same Anonymous Monk of Re: Win32::EventLog not returning all events? and if so what a pity you are no a named one to track of your post.. anyway thanks!
I have add a FURTHER READINGS section (and put them all uppercase..) to my pod pointing to these and more articles.
about code style
I have localized my $Win32::EventLog::GetMessageText occurence: as I said probably i'll strip out the reading part into a Win32::Event2Log::Reader submodule. The best place for this variable will be just after the, eventual, require Win32::EventLog one. Anyway this means you read my code.. someone read my code!! I must tell to my wife! ;=)
The red flag about dates is received, mea culpa, I'll clean the example (following your hints) before publishing the module.
about the name
ok no 2 in the name: Win32::EventFilter (without the S?) sounds good. Considering the above abstraction I mentioned probably Win32::Event::Engine will be more appropriate, no?
Anyway no, I do not think i'm writing an App::* like think. It's more similar modular engine, rule based. As side note, during my preliminar readings, I read perlmodstyle and I noticed i broke Designing your API suggestions, precisely Separate functionality from output one. But what can I do? The engine must show itself some output (on verbosity at least). It is designed to run forever (or to terminate at endtime ..) so it's like a webserver so some output directly from the module can be useful.
Thanks again for your help
update Feb 09: asked here how to subclass and separate module functionalities.
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.