1. I added the Authorization lock thingy to the interface, which was fairly painless... but! The security frameworks that make it painless turned out to be OS X 10.3 only! That's a real drag - I really don't want to drop 10.2 support at this stage. Unless anyone knows of a relatively painless way of incorporating the functionality in a 10.2 app, or has any other suggestions, I may have to drop it completely.
2. A while back the issue of startAuthoxy reporting success after a reboot, but Authoxy not actually starting, was brought up. I had seen the issue before, but it seemed to fix itself, oddly enough. Recently I was working on a client's computer (actually a friend who lives near by!) and switched her Ethernet network connection from Manual to DHCP. Authoxy, which had never successfully started immediately after a reboot, started successfully the very next reboot. Strange stuff indeed. So the wrap-up is, I haven't discovered any changes I can actually make to Authoxy to make this more reliable. Instead it seems to be a networking startup glitch.
3. There is an on-going issue of the Authoxy interface losing track of the state of the daemon. In particular, it may report no daemon running when there is actually one running, and therefore an attempt to "Start" the daemon results in an error about the port already being in use. Whenever I ran into this issue, I thought it must be because I'd been mucking around during development or something, and could drop into the Terminal and execute the "killall authoxyd" command to reset things back to normal. The fact that others are starting to report the issue suggests that we need a friendly solution. I'm considering maybe a "Force Reset" option in Authoxy which issues the "killall" (which unfortunately, not everyone will have installed), or some other function which forces a refresh of the status of the daemon.
4. WRT to the System Preferences crashes reported recently - if it is in fact Authoxy's fault, then there will be detail about Authoxy in the Sys Pref's crash report. I'd probably need that report to do anything about it. I have had quite a few reports in the past about stability issues when switching network connections, but unfortunately, have never found anything that would suggest Authoxy is involved (unfortunately because if I had, I might be able to do something about it!).
5. WRT to the Messages tab becoming unstable, that's something I can definately do something about. My system log tends to get swamped with information, but then I'm fairly particular about clearing it out often. I'm positive not everyone is so inclined. With that in mind, I will look reducing the amount of work Authoxy performs when parsing that log, particularly if it has grown large.
6. In the same vein, there are lots of messages I can now move into the "Write debugging information to the log" option. In particular, a lot of the NTLM messages were written regardless of that preference, so the information would always be there. Since NTLM appears to be working okay for a group of people, it would be much friendly to not dump all the garbage in normal operation.
Well that ought to keep me busy for the short term anyway. But of course, if you have any other suggestions, I'd be happy to ignore... I mean, consider them!
Regards, Heath -- ____________________________________________________________________ | Heath Raftery <[EMAIL PROTECTED]> | | HRSoftWorks <http://www.hrsoftworks.net> | | | | *The search for a new personality is futile; what is fruitful is | | the interest the old personality can take in new activities* | | _\|/_ | |____________________________________m(. .)m_________________________|