Growl is simply the underlying notification system, it is up to third party devs to include growl support in their apps. There are plugins for several of the built-in applications. For instance, iTunes, Apple Mail, and Safari. It supports sending/recieving notifications over a network.

Growl is just one of those things that I miss when I have to use a PC. I don't know of any similar service for windows.

Let me try to re-explain more clearly, as my last post was indeed confusing.

Growl is a 3rd party notification framework. Many 3rd party applications support the framework. As long as Growl is installed and enabled in the 3rd party app, notifications will be sent (see crappy diagram)

App -> Growl -> output

There are a number of configurable output options, ie to the screen, to a log file, across a network. More than one output can be active at once; you can have notifications logged, displayed on the screen, and sent across the network. There are several sub-options for each, most notably, the configuration of the on screen notifications.

Getting back to your question, growl support is NOT built-in to the standard apple applications, which is why the plugins are required. In each app that I mentioned, the plugin simply monitors that app, and forwards appropriate info to growl.

Growl relies on the graphics handling built in to os x, and is probably not possible to port, in its current form, to anything else.

For more info, and a much better description, check out http://growl.info/
and http://growl.info/documentation/growl-h … t-work.php in particular.

Displaying messages that are being broadcast over a network is a LOT different than porting the entire growl application.

A growl plugin could update a file on a webserver that was then re-downloaded to the chumby, but growl already supports forwarding messages over a network. Why re-invent the wheel? Why not simply allow the chumby to receive info from the local network?

I don't have a Chumby to test any of this on, mind you, but I can't see why it would be that difficult.

I'll do some more research into how growl works, but it does seem that it's somewhat a "push" type notification system - it will initiate notification messages, and somebody has to be out there actively listening for them.

As mentioned, Flash's built-in networking is pretty much limited to initiating its own fetches, typically for XML over HTTP.

However, Flash Lite has the notion of "extended events", whereby one can create handlers in Flash for events that are generated externally - this was done by Macromedia to handle things like incoming calls, etc for mobile devices.

I'll see if there's some way to exploit that mechanism for situations like this one.

All good suggestions chedabob...

Not knowing a lot about software, but would some of these things be possible with RSS?
If I can, I would like to use chumby for notifications of updates to my wikis etc. I think someone agreed elsewhere that this will be possible. Just wondering if the RSS stuff could be creatively used to do other things too...

While Actionscript does indeed support a "file://" protocol handler, it doesn't allow them for Flash movies coming from the Internet for security reasons.

Otherwise, you could create a Flash movie that reads arbitrary files from the hard disk and uploads the contents to some remote site.

Growl's not all that helpful either. I only have one Mac in the house, so sadly I can't test out the computer-to-computer feature (and thusly I can't get a log of what's being sent across the network and reverse engineer it).  Looking in the source, it's deeply rooted into Cocoa, which I am not all that familiar with and it would take time for me to go through and figure out what's going on. If someone else wants to provide me with network dumps from Growl-to-growl communications or wants to describe how Growl's inter-computer networking protocol works, it'd be very helpful.

However, the back half of the Growl-to-Chumby chain is the easier part to complete, and something I'm already scripting up in python (just for rapid development; I'll write a somewhat more "formal protocol" for it so anyone can implement it in any language they choose for any OS they choose later). It basically will be able to create an RSS feed of events, which means it'll be readily usable by the existing Chumby RSS reader. The only problem I'm already thinking about trying to get around is authenticating that its a Chumby (or otherwise authorized viewer), and not Joe Hacker who discovered your feed via a port scanner (this isn't a problem as long as people use firewalls, but with thousands of Open WAPs named Linksys...) I'm not exactly sure how Flash can do authentication (other than the obvious dumping a GET command like ?pwd=chumbie on the end of RSS feed and having my python script not respond unless that flag's there, which isn't great, but it's better than nothing and randomizable).

Oh, I should also note about the cross-platformability about this: Right now, as currently implemented, Growl is heavily anchored to OS X (as in, all of its functionalities except its encryption engine are implemented directly in Cocoa), so Growl isn't going cross-platform. It just can't happen. However, Growl-to-Growl may some day go from Growl-to-Galago (http://www.galago-project.org/ ). Porting Galago to Chumby, however, probably will be a daunting task, as it's dependent on D-Bus. Now if Windows only had this kind of framework...

what if we wrote our own thing? base it on RSS? cos a lot of applications can write their status to the web (e.g. winamp), so you could run a small server on your pc, that had php, convert it to an rss feed, then get the chumby to grab it. its a botched way, but at least it works, and it shouldnt be too hard to intergrate into other things (id love to see what status my router was in, the status of bittorrent downloads, status of my xbox media center).

This is what I was trying to achieve with the chumby XML-RPC protocol I was toying with some time ago.

The easiest (and most reliable) way to achieve this is by having an (internet) hosted service which client side plugins can call. This also means that you can galavant around with yonder chumby and still have your notifications follow you. Having it hosted also means you don't have to deal with NAT traversal, VPNs, anything like that - the average end user does NOT want to have to deal with that kinda... well, crap!

Duane is right - there is no standard notification protocol (apart from SOAP, which kinda is what we're looking for) that we can base it on. Sure, a constantly refreshing RSS is a solution, but it's hardly elegant. Keeping a HTTP connection open and streaming data to the client is another possible solution, however inelegant that may be.

Discuss?

Very gentle reminder...please provide a link to an image hosted elsewhere rather than uploading them in your posts...Thank you!