> > * Rolling file logger so the number of files on a disk don’t get huge and > the size of the logs stays small > * Separate files for different types of logs. Sync/Browser/Keychahin >
Some additional context on this: Until now (or recently? perhaps someone fixed this) we only kept one browser log. We'd like for that to roll, too; lots of bugs involve switching in and out of the browser, and we lose the old logs. It's not strictly necessary to keep separate logs for different parts of the app; that's a nice-to-have. Keeping Sync and Browser logs separate will help us in the future if we ever automatically send those Sync logs anywhere. We don't right now, so the only benefit to doing so is making it easier to figure out what's happening: it's hard to read a browser log with five hundred lines of Sync output, and it sucks to hit a cleanup pass that deletes vital logging in one component because another happened to be verbose. I think we should still swap it out with a logging framework that better >> handles these failures. Or maybe better, does not depend on NSFileHandle at >> all and instead for example uses iOS’ ASL library to do logging. >> >> I think it may be worth it to look at the code of the two suggested >> alternatives and see if they are more robust. >> >> I feel like Stefan's point here is the key: this decision isn't driven by the API: that's easy to wrap or change. Instead, it should be driven by an examination of how each of these libraries is implemented. A pure Swift lib which uses safe calls to write, but has a simplistic API, is a better choice than a full-featured API built on top of a shaky ObjC foundation.
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
