notify.io

[Jeff Lindsay]

Let's get this project rolling! The original plan was to do the client as a FF plugin that could later be abstracted into a XULRunner app and then someday we actually integrate with Growl, etc.

We talked about it using XMPP and we have an XMPP server set up ... however, I'm leaning towards long-running HTTP. I even have software that can be used for the server!

Abi, if you want to get started on a client, try playing with Hookah (http://github.com/progrium/hookah) and the Stream interface. It's almost just like the Twitter Stream API.

--
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

[Jeff Lindsay]

Ok, I've got a working API server that can stream JSON over long running HTTP. I have my own client in python right now, so all we need is a better cross platform one and we have a working system. I'll be putting things online in the next few days.

[briandunnington]

is your JSON format specified online anywhere? i know the original
discussion on the Yip/Silent Diving Seagulls post mentioned it being
simply title/text/icon or something like that.

i would recommend that a more flexible data structure be used - it is
only a matter of time before people will want to add other data, like
application name, priorities, sounds to play, notification groups,
etc. these might seem like useless properties now, but having a
flexible format allows future growth.

you probably dont want to move away from JSON, but i would invite you
to look at the GNTP format - it is more like a MIME/HTTP-style data
format (name: value headers). the advantages are:

1. already has support for additional (optional) properties like
Priority and others
2. has a built-in mechanism for allowing non-standard custom
properties (X-property style)
3. allows for text and binary properties (for sending embedded image
data for example, rather than linking to a url)
4. already supported in Growl for Windows (adding HTTP long polling to
the notify.io servers would be trivial) and will (soon? maybe?) be
supported in Growl/OSX as well.

in its simplest form, a GNTP notification is only slightly more bytes
than a JSON-style packet, and the custom properties and binary data
are all completely optional. the ability to easily extend the data
format and its use in existing apps make it an attractive alternative.
the full spec can be viewed at this link: http://www.growlforwindows.com/gfw/help/gntp.aspx
- it looks long and scary, but we are only dealing with a small subset
of it (NOTIFY command) it is really quite simple.

just my 2 cents.

On Sep 28, 7:59 pm, Jeff Lindsay <progr...@gmail.com> wrote:
> Ok, I've got a working API server that can stream JSON over long running
> HTTP. I have my own client in python right now, so all we need is a better
> cross platform one and we have a working system. I'll be putting things
> online in the next few days.
>
>
>
> On Fri, Sep 18, 2009 at 8:58 PM, Jeff Lindsay <progr...@gmail.com> wrote:
> > Let's get this project rolling! The original plan was to do the client as a
> > FF plugin that could later be abstracted into a XULRunner app and then
> > someday we actually integrate with Growl, etc.
>
> > We talked about it using XMPP and we have an XMPP server set up ...
> > however, I'm leaning towards long-running HTTP. I even have software that
> > can be used for the server!
>
> > Abi, if you want to get started on a client, try playing with Hookah (
> >http://github.com/progrium/hookah) and the Stream interface. It's almost
> > just like the Twitter Stream API.
>
> > --
> > 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
>
> --
> Jeff Lindsayhttp://webhooks.org-- Make the web more programmablehttp://shdh.org-- A party for hackers and thinkershttp://tigdb.com-- Discover indie gameshttp://progrium.com-- More interesting things

[Jeff Lindsay]

Cool. It's basically a json object with text, title, icon, sticky, and link (notify.io assumes a url based action when clicking). I'd stumbled upon GNTP ... I'm not entirely sure I understand why they think they need their own protocol/format. It's something I'd be willing to support if there was demand by client makers and was useful.

notify.io will have a way of talking to most system notifiers, so it will probably be normalized to a simple data model like it is now. Anyway, I too get caught up in over-thinking and over-designing... it's best to actually build, build pragmatically, and get it used and be driven by users.

[Brian Dunnington]

> Cool. It's basically a json object with text, title, icon, sticky, and link
> (notify.io assumes a url based action when clicking). I'd stumbled upon GNTP
> ... I'm not entirely sure I understand why they think they need their own
> protocol/format. It's something I'd be willing to support if there was
> demand by client makers and was useful.

just like you needed to decide on a standard set of properties and a
data format for notify.io, that was the same motivator behind GNTP. in
the end, the group chose a different data format (a JSON-style format
was also considered) for various reasons based on their goals (keeping
in mind that they were trying to come up with a format that worked
equally well for local applications that were not going through a
centralized server, they wanted to be able to parse the request as a
stream without having to read the entire request, etc). there are
always pros and cons of any architectural decision like that.

> notify.io will have a way of talking to most system notifiers, so it will
> probably be normalized to a simple data model like it is now. Anyway, I too
> get caught up in over-thinking and over-designing... it's best to actually
> build, build pragmatically, and get it used and be driven by users.

agreed. that is why i suggested GNTP actually. although Growl for
Windows' user base is not huge, there are several thousand people who
use it constantly every day for a wide variety of use cases. it has
been in general use for over 6 months, so there has been lots of time
to work out any kinks. there are client libraries written in almost
every language (including Javascript, Perl, Ruby, Java, PHP, Python
and more), so it is easy for app developers to integrate.

a simple JSON style format is obviously easy to use and thus appealing
in that regard. i just wanted to throw an alternative out there while
you were still early in the game to see if it fit. hopefully you can
publish a quick sample so others can start playing around with what
you have so far.

[Jeff Lindsay]

Good points. I'll work on providing a GNTP stream, along with JSON. It's such a minor part of the whole picture, it doesn't matter to me a whole lot. I haven't looked through the spec yet, but is there a recommended mime type for GNTP data? application/gntp?

[briandunnington]

> Good points. I'll work on providing a GNTP stream, along with JSON. It's
> such a minor part of the whole picture, it doesn't matter to me a whole lot.

yeah - i kind of suspected that you were going to offer the data in
multiple formats to work with various clients since, in the end, they
are all describing the same notification details. thanks for taking a
look - it may not even be a good fit, just wanted to toss the idea
out.

> I haven't looked through the spec yet, but is there a recommended mime type
> for GNTP data? application/gntp?

since the rest of the spec deals with GNTP over TCP, there is no mime
type specified. however, in my personal hacking, i have been using
application/gntp as the mime type when playing with GNTP over HTTP. i
guess it is not 'official', but it is probably the right answer.