Tylor, he never said it wasn't enough, he's just wanting other options.
THIS!
someone, sending everything maybe good enough for syslog to handle but adds more resource usage to Anope it's self. By Anope using it's own logging system it's far easier to keep control of as well as expand upon. Additionally, using internal methods cuts back on relying on external applications.
DUDE!
What is faster: writing to 1) heavily used hdd, 2) moderately used hdd or 3) to ram?
So given the possibility to NAME a SINGLE logfile (which can be a named pipe to a syslogd), you could pipe ANY output directly to the syslogd (without the data ever going to a hdd)
Now if you want to tell me, that this puts more straint on the machine, than anope writing to a physical hdd, i should stop arguing as it would be as useful as explaining some people who never saw a computer, how cool the internet is.
Also the argument, its more tidy is invalid.
There is no benefit of keeping logfiles in the programs directory. Not on windows not on linux.
Actually, if anope dies, there will be logfiles, that will never get automatically deleted - oh yeah!
You can also have mutliple partitions/hdds (again, on win and on linux) having diffrent configuration for diffrent pusposes.
So it *MIGHT* be very, very ressource consuming/slow, if you are forced to write to on an allready heavy loaded hdd, instead on a moderately loaded log-hdd...
Also the external programs you are talking about are linux's (and windows) core fetures, WHY not use them?
Its like, if THEY break, the least probem you have to deal with is anope or irc...
But yes, there is not much of a benefit for windows users, as win's syslog is pretty good hidden AND hard to access.
Finally, your "50c shell" example is hardly accurate. Everyone deserves logs and besides the sysadmin of the shell company might not want 100 different Anope's hogging up syslog whilst important global logging needs to be done.
As i said: per user logfiles.
Works like a charm!
As far as the feature request it's self goes, I see no harm in it truthfully. Of course that would require a huge undertaking since the logging, db, core bots as well as countless other areas aren't so modular as other services packages are in these areas.
DUDE, NO!
*ALL* you need to change, is the function that gives the logfiles their names.
If you can define a single name, instead getting forced into a logs directory with date-appended files, you are done.
it would take like one config parameter that defaults to:
LogFileName = "logs/service.{DATE}.log"
Ppl like me could then simply change this parameter to stuff like "/dev/log" or ppl that do not want logging at all could stick with "/dev/null"
I guess we allready wrote more, than it would need to change the code
