On Mar 26, 2009, at 5:02 AM, Peter Hosey wrote:
> > On Mar 25, 2009, at 07:27:13, rlhamil wrote: [...] >> * The page above mentions UDP port 9887, but says "The UDP protocol >> is not advertised because its port number is configurable by the >> user." However, while the preference pane certainly _tells_ me the >> TCP and UDP port numbers, I don't see any option to configure them. >> Are they only configurable by altering the source code? > > No; you can use Mac OS X's user defaults system to set the port. That > requires a command such as: > > defaults write com.growl.growlhelperapp GrowlUDPPort -int 42000 > > However, unless your users are comfortable in the terminal, feel like > diving into our source code to learn how to change the port, and even > know that it's changeable, I wouldn't worry about it. > > 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, since the page said the UDP doesn't use Bonjour; I gather the more sophisticated TCP protocol would take me out of the realm of pure C, and even if I could use Bonjour with the UDP protocol, that adds more complications than I'd care for if trying to do minimal mods to existing C apps. 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, issues involving multiple console users shouldn't matter, at least not not for what I'm doing now, in the context of most "wall" messages being issued automatically by (non-Apple) NFS servers to their clients when the server goes down (since client accesses to NFS hard-mounted files will simply hang until the server comes back up). And 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. Presumably most Growl notifications are delivered via some local communications channel, which _is_ per user, which would presumably mean that even a user that was logged in but not the currently active user would get those. 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. (not such a biggie if non-current users didn't see the message; just tell 'em not to use fast user switching, let's say...) 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 (unlike using VNC on a Mac or Windows, which only remotes the current console session). So if you want to work in such an environment (not that I'll ever see one!), you'd probably have to deal with the possibility of multiple graphical user sessions anyway. 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. 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. 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. 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. If the UDP listener were split off, that might be system-level rather than per-user policy too, which would be better in the case of the terminal server scenario (keep the users from spamming each other or using it as an unauthorized inter-user communications mechanism), although if the authorization status could be detected after being passed on via the local channel, a user could still choose to ignore unauthenticated messages even if the system accepted them. BTW, I found an existing C binding for the UDP Growl protocol, just a .c and .h file that are part of something larger. Unfortunately, they're (a) GPL'd, and while they'd work for me, (b) they could be generalized a bit more to be a truly generic C binding. I've just now sent a message to the author asking him (?) to consider making those two files available under LGPL or BSD, to simplify linking them to minimally modified existing C/ Unix code, much of which is likely to be BSD, APSL, or CDDL, the latter two not being GPL compatible. I'll pass on what I hear. If he doesn't want to do that, I'll probably have to whip up something myself. I am thinking that you guys really could use a C binding for that, because there are probably a few other C apps (small "a", not Mac application bundles) that could also benefit from a Growl interface. 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? 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. I tried to find prior references to that particular question, but while a google on apple incorporated growl had the first hit being a blog post or something that included that very question, the rest were way too many non-obviously (from the short summary of the match) hits, nor could I think of better keywords to search for. Ok, having worked a mid shift and now written way too much, I can't keep my eyes open any longer..._why_ do I always manage to get myself into too much research and too many design issues? :-) No, that's just rhetorical, I'm not really asking you folks that one. 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
