On Mar 26, 2009, at 11:58:58, Richard L. Hamilton wrote: > On Mar 26, 2009, at 5:02 AM, Peter Hosey wrote: >> Perhaps if you intend to release your notifier to the public, you >> may want to make the port configurable. Or use Bonjour. > > I could do the former, although not the latter without modifying > your code, …
Why? It's just a user default, so you could make a small tool, perhaps using Platypus, to allow users or admins to easily change the port Growl listens on. Ideally, your rpc.walld could even look in each user's preferences to find the correct port to use to connect to their Growl. > … since the page said the UDP doesn't use Bonjour; … Oops. Right. Sorry. > … I gather the more sophisticated TCP protocol would take me out of > the realm of pure C, … Right: It's Cocoa Distributed Objects. We're working on a new platform- agnostic protocol, primarily for use over TCP. We don't know when it will make it into a Growl release. > Also, a per-system process probably isn't going to want to deal with > per-user preferences, _except_ via Bonjour. For a workstation, it > might just barely be possible to figure out somehow who the > _current_ GUI session user is, but that would require excessive > privileges, and there's a scenario (below) that still presents > problems. > >>> * is growlnotify reliable enough that I could just posix_spawn() >>> it, which would avoid all the issues with a network connection? >> >> When using the UDP protocol, yes it is. However, only one user's >> GrowlHelperApp can bind a socket on our UDP port at a time, which >> means only one user per machine will see your notifications. > [...] > > … on a workstation, AFAIK only one console user can actually be > _active_ at a time, although others could well have processes > running given fast user switching. Right. That would mitigate the problem, except that Growl binds the socket only on launch, not on session-resume. That means that (in my testing) the last Growl to bind wins, and all the others come unbound and won't receive network notifications, even when the user who owns one of those processes resumes his session. > Presumably most Growl notifications are delivered via some local > communications channel, … Cocoa Distributed Objects (which work locally as well as over a network). > … which _is_ per user, … The documentation for NSConnection suggests that it's per-host, but that seems counter-intuitive for local connections, and I seem to remember having multiple Growls running and working with local notifications. > The only problem I see is that with fast user switching, if a user > other than the current one could be bound to the port, then the > current user would never > see the message. Exactly. > But on a Mac _server_, I believe there are one or more commercial > terminal server software packages available, that act much as WTS or > Citrix do for Windows, allowing multiple simultaneous graphical > sessions to be accessed via some remote display mechanism… Yeah. One way or another, we should definitely do the right thing for concurrent logged-in users at some point. > I gather it is sort of possible, if tedious, to have system and user > processes communicate, if not readily with Mach ports, then perhaps > with Unix Domain sockets or named pipes or some such. Pipes are one-way, and Growl notifications can be two-way sessions (if the application asks to know when you click the notification or let it time out). The long-term solution is sockets, with a two-factor implementation, such as the one I suggested in my previous message and you echoed: > In which case, perhaps there should be a single listener with system- > wide policy for network notifications, which in turn passes them on > via a purely local communications mechanism to any user > GrowlHelperApps running, that can filter them further as they wish. Yup. A daemon to handle network notifications, and one agent (GrowlHelperApp) per user session to handle local notifications. The daemon would forward network notifications locally to the agent. Further reading: http://developer.apple.com/technotes/tn2005/tn2083.html (GrowlHelperApp isn't a *launchd* agent, and I haven't read enough of that technote yet to know whether it'd be worth changing it over to be one. I doubt it.) One thing we'd have to be careful about is making sure that the daemon handles dispatching the notifications to the users' GHAs based on the users' hostname whitelists. Otherwise, every user would see every incoming network notification—bad for privacy. > Next, I don't pretend to understand either Objective C or Apple's > CoreFoundation framework, but it appears to me from an incredibly > cursory look at the code that you can tell the IP address of where a > network notification came from. I believe that's true of sockets in general, although I'm no expert in that API. > Which should make it possible to add an option to allow > unauthenticated network notifications from localhost (127.0.0.1 or :: > 1 for IPv6), even if authentication was required for everyone else. That's the basic idea. GHA should accept notifications locally only (i.e., only from localhost), whereas the network-notification receptionist daemon should accept notifications only from the network (not from localhost). > Which leads me to one last thing, and I hope this is neither a FAQ > nor inflammatory, as I mean no offense: I wonder why Apple hasn't > picked up Growl and incorporated it as a standard solution to fill > in their shortfall in that regard? It is sort of a FAQ, although most users who say it phrase it as a statement. ☺ We agree: It certainly would be cool if they bundled Growl. > Certainly once some of the cases regarding network notification > (like multiple users on a terminal server) are solved, I think it > would be very handy indeed if it were available on every Mac, right > out of the box (and documented along with the rest of their apps and > libraries); that > would no doubt get a lot more apps using it. Indeed. > But at least you know now why I've rambled on so much. Believe it > or not, I _did_ edit this message quite a bit before posting. I've been there. ☺ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Growl Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en -~----------~----~----~----~------~----~------~--~---
