You might want to consider renaming this project. The NS prefix is reserved by apple for framework classes. The entire purpose of prefixing classes in Cocoa is to prevent namespace collisions between different organizations, which using NS outside of apple breaks. It doesn't actually look like you are using the NS prefix in any of your code, so you're not technically violating the below rule, but I still think it worth considering. NS kindof means "from apple".<p>"Objective-C classes must be named uniquely not only within the code that you’re writing in a project, but also across any frameworks or bundles you might be including. As an example, you should avoid using generic class names like ViewController or TextParser because it’s possible a framework you include in your app may fail to follow conventions and create classes with the same names.<p>In order to keep class names unique, the convention is to use prefixes on all classes. You’ll have noticed that Cocoa and Cocoa Touch class names typically start either with NS or UI. Two-letter prefixes like these are reserved by Apple for use in framework classes...<p>Your own classes should use three letter prefixes. These might relate to a combination of your company name and your app name, or even a specific component within your app. As an example, if your company were called Whispering Oak, and you were developing a game called Zebra Surprise, you might choose WZS or WOZ as your class prefix."<p><a href="http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/ProgrammingWithObjectiveC/Conventions/Conventions.html" rel="nofollow">http://developer.apple.com/library/ios/#documentation/cocoa/...</a><p>In practice many people use two letter prefixes for their classes, you should use a prefix with your classes!<p>The project looks great, I've been wishing for a more comprehensive logging system with filtering built in for a while now. Thanks!
The log viewer and query tools looks excellent.<p>Here are some (hopefully) constructive comments:<p>- As others have mentioned, change the NS prefix. Only Apple should be using that.<p>- The API is not canonical looking Objective-C/Cocoa. It looks like the programmer has a Windows/C++ background<p>- I only took a quick look but I didn't see logging macros that conditionally compile out logging for release builds<p>- Internally the logger uses pthreads. This is going to make it difficult on a client that uses Grand Central Dispatch to reason about code when they are debugging something. Consider using queues and operations rather than firing up worker threads. Take a look at CocoaLumberjack for their approach<p>- Create a Cocoapod to spur adoption
Damn, I have dreamt of something like this for a while, but never sat down to build it. I can't wait to try this out in my next project. A remote client is brilliant, and would have really saved my bacon about a year ago when testing an application in the real world.<p>I would agree, though, to avoid the "NS*" prefix, but that's been spelled out in a different thread.
Honest question: why does everybody seem to want to compile out logging on release builds? Yes, if you're "printf debugging" that probably shouldn't be in a release build. But I've found the ability to look at (optional, user-enabled) logs invaluable in tracking down some obscure bugs in production.
Have used this in combination with CocoaLumberjack on a good number of projects and it has come in VERY handy. Highly recommended.<p>Not too difficult to get it wired up with papertrailapp.com either - That combo makes it VERY handy