http://www.perlmonks.org?node_id=1208315


in reply to Re: RFC Win32::Event2Log ..gimme back my logfiles
in thread RFC Win32::Event2Log ..gimme back my logfiles

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

L*

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.