notify.io growl fork

[Jeff Lindsay]

Good news! A friend of mine is helping add a long-polling client to Growl. =D

--
Jeff Lindsay
http://webhooks.org -- Make the web more programmable
http://shdh.org -- A party for hackers and thinkers
http://tigdb.com -- Discover indie games
http://progrium.com -- More interesting things

[Chris Forsythe]

That's news to me that someone is adding something to Growl. Do you mean he's making a third party utility for use with Growl?

Is your friend using gntp or the older network protocol?

Chris

[Jeff Lindsay]

Well, it's a fork. Neither network protocol.

[Chris Forsythe]

I guess I'm confused, so someone is forking Growl? Maybe I misunderstand the point of this mailing list, pardon my ignorance if so. However, you're using the words fork and Growl in the same sentence, which is concerning since we would probably accept most changes that someone could come up with for Growl itself.

Chris

[Jeff Lindsay]

Sorry, I'm used to Git terminology. We're patching it. If you accept patches, then yay! I wasn't in a hurry to explore the potential politics of that sort of thing. We just want something that works.

[Chris Forsythe]

Ya, we accept patches, just tell us what you're wanting to implement (long-polling probably needs to be presented with an actual use case, since that may or may not be understood by some people). We use mercurial, check out our dev docs on how to grab the current tree.

If it's not a really big gui change or a gui change at all, then it's more likely to be accepted.

I've never used Git, so when you said Fork, to me in OSS projects that typically means that someone is so angry with the politics of your project that they have to split off. Which is why I was concerned, since we only have 4 or 5 people total on the project, and everyone agrees with each other.

Chris

[Jeff Lindsay]

Here's the mini spec of what we're working on. Eventually it might want a UI, but we wanted to avoid that for now. Obviously, this would need to be generalized a bit to make sense in Growl proper.

When Growl starts it will check for a file in your home directory call .notifyio that contains a URL. This is a listen URL for notify.io -- it will hold an open connection to this (reconnecting if disconnected) and listen for JSON objects. The objects will contain notifications params (essentially text, title, icon, link, sticky) and when received, they're displayed with Growl. A python equivalent of this as a standalone client is here: http://github.com/progrium/notify-io/blob/master/api/client.py

Thats pretty much it! It allows for Growl to accept network notifications from behind the firewall, in this case from a service made to broker notifications, but it could easily be any Comet-style stream of notifications. On this list we talked about streaming in a GNTP format, and maybe that would be more proper for Growl proper ... I just find JSON more pragmatic for the moment. Perhaps both can be supported in the client, as I was planning on streaming both from notify.io ...

Thoughts?

-jeff

[Peter Hosey]

On Oct 6, 2009, at 23:00:21, Jeff Lindsay wrote:
> When Growl starts it will check for a file in your home directory
> call .notifyio that contains a URL. This is a listen URL

> fornotify.io -- it will hold an open connection to this

> (reconnecting if disconnected) and listen for JSON objects. The
> objects will contain notifications params (essentially text, title,
> icon, link, sticky) and when received, they're displayed with Growl.

Your friend will want to write a pathway class, then. See GrowlPathway
and its subclasses.