On Wed, Dec 7, 2011 at 10:38 AM, Jason Smith <[email protected]> wrote: > Thanks, Benoit. > > I would like to move the discussion back, one hundred percent, to > identifying exactly what features are good and bad for CouchDB. We are > in no hurry. IMHO, CouchDB does not need a patch soon. It needs > thoughtful, deliberate planning.
yes and no . We don't need to be 100% to start implementation. For example we could just replace our current logger by lagger which would give us automatically support for different backend, log rotations & co and prepare for more attributes as well. > > More responses inline. > > On Wed, Dec 7, 2011 at 3:06 PM, Benoit Chesneau <[email protected]> wrote: >> I fully agree, we need better logging in couch. I don't really like >> the idea of saving any data structures, but why not. Imo such things >> could be saved as binaries strings and then parse but ... > > I agree. For the first milestone I propose no change to the logs: the > same ?LOG_DEBUG() macros, the same text file; the same log format only > a mother could love. > > When I say "data structures," I simply mean that more useful > information is available to be logged. > ok so you're speaking about log arguments? > A first milestone might to output to the same log file as before. > However, I hope it would be easy to write different log formatters for > different needs: > > * Web developer format: client IP, method, headers, log message > * Erlang troubleshooting format: PID, supervision tree, heap usage, log > message well such infos should be natural since the code doesn't hangs at the same place. you don't have the same info then. > > For the first milestone, though, something modest: > > * Traditional format: timestamp, log level, pid, log message // i.e. > what Couch does now > again lagger do a lot of thing about that. Technically I really like its possibilities. And we don't have to reinvent the wheel . I woul dbe curious anyway how cloudant is comparing twig to it. - benoît
