In August, I will be implementing a TCP-based networking protocol for  
Growl and will be continuing to improve networking in general.

What TCP-based networking protocol? That's where this email and you,  
dear reader, come in.

1. The protocol should be relatively easy for both sender and receiver.
2. It should not be platform-dependent.
3. We need to have some form of authentication, preferably with  
encryption of notifications so that there are no concerns with sending  
potentially sensitive data over the wire.  That encryption, keeping  
with (1) and (2), should be straightforward for a wide variety of  
platforms to use.

Peter and I discussed the protocol a bit off-list already.

I initially suggested an XML-based protocol, as XML is easy to read  
(for a human) and straightforward to write and parse in most languages  
given the wide variety of XML libraries available.  This would look  
something like:
<notification>
        <title>Something happened!</title>
        <description>This thing happened, and I thought you should know.</
description>
        <image>base64-encoded-image</image>
</notification>

However, he pointed out that the majority of the data in a  
notification is the image data, and raw bits and XML don't mix,  
necessitating base64 encoding or the like. Also, the full document  
must be parsed for it to make sense.  If, instead, we could indicate  
the number of bytes to follow were to be interpreted literally, that  
would be a computational savings.  (Peter, please clarify if I  
misunderstood any of that)

His counter-suggestion was something similar to MIME headers, like this:

Action: Notification
Title: Something happened!
Description: This thing happened, and I thought you should know.
Image: 103908
<103908 bytes of image data>

Any thoughts or preferences for one approach versus the other?

Also, I have no experience in the production of a secure protocol.  We  
just need to be able to say, "Is the same password (or lack of  
password) being specified on both ends?" with that password being the  
decryptor for the message, I think.  Could someone with more knowledge  
than that expand on those thoughts with what might be an appropriate  
authentication system?

Cheers,
Evan

PGP.sig < 1K Download

I assume you mean one central server and many clients?  If so, I assume
the clients are pushing?  If it's distributive, are you planning on
pushing or pulling?

This could probably be easily rectified by something like xmlrpc over htt=
ps.

I assume the text would be a constant encoding, something like utf-8 or
would be specified.  Also, is this supposed to be like http headers?
Also, what happens if a description has an embed newline in.

I'd say go with an xmlrpc approach passing a url to the image's in the
main notification chunk.  Thus if this is being pushed (see above about
the push/pull question) to a client that doesn't have a graphics
environment, there is no need for it to grab an image it can't use.

Developing secure protocols is no easy task, which is why I'd suggest
xmlrpc over https, but of course, then you need ssl certs.  You could
use shared key encryption, but again, you need a way to pass the key.
You could also use an existing crypter using a password as the salt, but
without any throttling, brute force attacks could be possible.

--=20
Gary Kramlich <g...@reaperworld.com>

signature.asc < 1K Download

On Aug 03, 2008, at 18:08:11, Evan Schoenberg wrote:

Not necessarily; it depends on the parser. expat, I think, can just  
suck XML straight off a file-descriptor (e.g., socket) without having  
to suck it all in at once. NSXMLParser, on the other hand, requires an  
entire document at once.

Aside from the above, you nailed it.

I would point out that we should not worry too much about details of  
various protocol suggestions. I think we should pick an overall scheme  
(XML, MIME, _____, _____, …) and refine from there.

Not that I have any experience in this, either, but we do want to not  
send passwords over the wire. We should use some sort of hash.  
Currently, I'd recommend one of the SHA family, such as SHA-1 or  
SHA-256.

As of OpenSSL 0.9.7l (included with Mac OS X 10.5.3), the openssl(1)  
command-line front end doesn't support SHA-256. Python does, however.  
I have no idea what hashing options are available on Windows.

On Aug 03, 2008, at 18:42:40, Gary Kramlich wrote:

That's our current system, and I think all thought we've given to a  
new protocol has been in the same direction. It's certainly a simple  
system.

That said, I, for one, am open to alternatives.

I dislike polling behavior, so I say that nodes in such a system  
should push notifications to other nodes.

Indeed, doesn't TLS solve the encryption problem neatly?

Not that I've ever used TLS at an API level.

Yeah, I was envisioning UTF-8. Header names would be ASCII.

Yup. Very similar to HTTP, actually, as the example below will show.

I considered this. We can provide a Description-Length header, as an  
alternative to Description:

---
NOTIFY Download succeeded
Protocol-Version: 1.0
Application-Name: GrowlSafari
Title: Download succeeded
Description-Length: 44
Image-Length: 1048576

File: Growl-1.2.dmg
Destination: ~/Downloads

<image bytes>
---

We may also want to provide a header that specifies the order of such  
payloads. In this case, it would be “Payloads: Description Image”.  
For every name specified in the value of that header, the length  
header would be “<name>-Length”.

Has anyone considered JSON?  It's a much lighter protocol than XML is  
(in bytes transmitted at least) and is very widely used already.

Secondly, how about simply sending a URL to the image to use rather  
than trying to send the image itself?  This means the end client can  
use O/S native ways of retrieving the image and there's no concern  
over big/little-endian formatting, etc.

On Aug 03, 2008, at 23:13:05, Chris Peel wrote:

How available are JSON parsers?

I know that on the Mac, there's a JSON framework that anybody can use  
(BSD-licensed, just like Growl). Are ready-made and easy-to-use JSON  
parsers also available for Windows and GTK?

Also, how does JSON handle binary data (such as images)? Would we have  
to rely on something like Base64 or, worse, URL-encoding?

Attractive for bandwidth reasons, in cases where the recipient doesn't  
need the image (notification turned off, non-visual display selected,  
etc.), but does it really matter, especially over a local network?  
Even through an intertube, you can send up to a few hundred K in a  
reasonable amount of time.

There's added complexity here: The sender must now implement a server  
of its own, in addition to connecting to a notification server, and  
the server must connect back to the sender, rather than passively  
waiting for everything to come to it.

Is it worth it?

I'd use XML based.  I've been working with Christian Hammond on coming  
up with a common protocol so that "growl servers" can talk to  
libnotifiy on linux and vice versa.  We had discussed doing it in  
XML.  While it requires base64 encoding, etc for binary data, it's  
easy enough to do that it's not terribly difficult to implement.

As far as passwords go, it could just as easily be Public/Private Key  
encrypted, where a key is specified for a host after the initial  
registration with the server.

/VInay
On Aug 3, 2008, at 6:08 PM, Evan Schoenberg wrote:

On Aug 04, 2008, at 00:18:54, Vinay Venkatesh wrote:

Sounds relevant to this thread. Would you mind inviting him to this  
list?

My experience with XML is that it usually involves one of:

1. Writing handlers for a stream-based parser, which is a pain in the  
ass
2. Slurping an entire document in at once, then processing it with  
XPath or something
3. Using a higher-level library that that does one of those for you

Based on this knowledge, I am not a fan.

For a MIME-style format, you could write your own parser and it'd  
*still* be simpler code than #1 and lower-overhead than #2. For JSON,  
you'd have to do #2, but it'd still be lower overhead than XML.

If there's any real advantage to XML, I'd love to hear it, but I  
haven't heard it yet.

Interesting. Advantages/disadvantages over plain hashing?

What do you mean?

<snip>
I assume by plain hashing you mean just the password?  If so, is there
nothing that growl could notify that might be considered "private" and
thus should be encrypted as well?

--
Gary Kramlich

I never designed a secure protocol but how about something like this:
1. Both sides generate a private/public key pairs.
2. Both sides exchange the public keys.
3. Both sides ask the user to provide a password, which should be  
identical on both machines.
4. Each side encrypts the hash of the password using its private key  
and sends it to the other side. The receiving side decrypts the hash  
and compares it with the hash of the password it holds. If both hashes  
match, the other side is trusted and its public key is saved.
5. All future communication is encrypted using the private/public keys.

Ofri

On 04/08/2008, at 04:08, Evan Schoenberg wrote:

Correction for step 4 - each side encrypts the hash using the other  
side's public key. I don't think it matter that much (won't be  
surprised if I'm wrong) but it just seems more correct.

Ofri

On 04/08/2008, at 15:30, Ofri wrote:

i would second the JSON approach - it is nice and easy, less verbose
than XML, and parsers should be available for every platform. i have
actually been thinking about this topic for quite awhile and will add
my thoughts, as well as a few questions. i uploaded a simple
description of what a JSON-based protocol might look like to the Files
section of this group if anyone wants to take a look at it (http://
groups.google.com/group/growl-development/web/
growl_protocol_proposal_json.txt?hl=en). some of the key points are:

 - image data can be passed in several formats, including using a URL
(http://site/image.jpg) or raw data (similar to the data:// urls
supported by browsers). that should allow enough flexibility for
different scenarios (desktop, network notifications, web-based, etc)

 - allow the inclusion of custom attributes in addition to the
standard ones. (ex: x-myAttribute). this would work similar to how
HTTP headers allow you to add custom headers. these custom attributes
could be used by the display notification or in the callback (see
below)

 - callbacks are specified in one of several formats, similar to image
data. they can be a URL or a special identifier that indicates to
local window/app that sent the notification. parameters can be passed
back with the callback, including custom attributes as specified
above.

i also have a few questions for the group. you said this should be TCP
based, but are you really just trying to figure out the data format? i
mean, could the same data format also be sent over UDP if desired (and
the Growl app supported it)? i know that several people have expressed
interest in the ability to broadcast notifications, and the ability to
'fire-and-forget' without requiring the client to acknowledge receipt
is very hand in many cases. i think that a standard data format is the
important piece here.

also, when you say you want a 'secure protocol', do you actually mean
you want the notifications encrypted, or do you simply want to verify
that the same password was used on both ends (similar to how it works
now). if it is the later, then using the password as a hash is the
easiest way to go. the password is never sent, and the authorization
check is easy. of course, this does NOT protect sensitive information
as it goes over the wire from being *read* (only from being modified).
if you want that as well, then a more complicated scheme needs to be
implemented.

in a thread in the Growl uses group, i think someone said that they
envisioned this protocol eventually replacing both the exisiting TCP
and UDP protocols - is that still the goal? if so, does that mean this
protocol will be used for network notifications, or for local
(desktop) type notifications as well? if the goal is to eventually be
cross platform, i would suggest that even local desktop apps use the
protocol to communicate - then there is only one type of message to
send whether your app is running locally or on the network or on the
internet. (in my Growl for Windows implementation, i used the UDP
protocol for the desktop notifications as well and it worked good,
minus the support for images and callback notifications that are not
part of that protocol).

On Aug 4, 5:34 am, Ofri <ofri.wol...@gmail.com> wrote:

also wanted to point out that the Gears team (formerly Google Gears)
are working on a Notifications API as well:

http://code.google.com/p/gears/wiki/NotificationAPI

this has not been released in any version of Gears yet and the actual
API details are not published, but i thought it might apply to this
discussion. not sure if we want to work with them to define the
standard or not, but just wanted to include anyone who was working on
something similar.

On Aug 04, 2008, at 15:59:50, briandunnington wrote:

Hm. Interesting. We probably should reach out to them and see if  
they'd like to get on board, too.

On Aug 04, 2008, at 10:56:43, briandunnington wrote:

I agree that they should be, but are they? :)

- Is there a JSON parser for Windows?
- Is there a JSON parser for Linux?

(Browsers and WebKit don't count.)

That URL is 404. We actually need to go to the Files area to view it:

        http://groups.google.com/group/growl-development/files

Thanks; it looks like a good example. I'd use MIME types instead of  
having these “IconFormat.Jpg” constants, but as I said, we can debate  
details later.

Supporting data: URLs themselves would relieve the need to specify the  
type separately. For an HTTP URL, the machine retrieving the image  
would probably use a HEAD request first to find out the type (or just  
blindly GET it and close the connection if it's not a usable type). A  
data: URL specifies the type itself.

Still incurs base64 overhead (encoding/decoding time, plus extra  
bandwidth), though.

Good point. I'm really not sure how to handle callbacks.

In the case of TCP, a two-way connection that lasts until the  
notification fades out or is clicked could work. (On the other hand,  
if we use a single connection for *everything*, from registration  
onward, click feedback could become more problematic. Am I wrong in  
that?)

I'm not sure what to do about UDP. Maintaining a queue of  
notifications waiting for click feedback is just asking for SYN-flood-
type problems.

At this time, yes.

Sure. (See below.)

Agreed.

I don't think we've decided that yet.

That was me, and yes, that's still what I want.

Yup.

Good idea. Eating our own dog food, as the saying goes.

I'm not sure that we'll do that, as I think it's more work for the  
framework—NSConnection is just *so easy*, and we already have it  
working. Nonetheless, using the new network protocol for both is a  
sound idea, and you may be able to convince me that we should do it.

comments inline below...

On Aug 4, 8:16 pm, Peter Hosey <p...@growl.info> wrote:

i cant speak for the C++/Win32 world, but .NET has JSON support built-
in. i am not a linux guy either, but i would bet money that there is a
JSON parser available.

agreed - the details are not as important as getting the concepts at
this point.

i think having a robust callback mechanism that works for any type of
app (local or remote) should be a key goal, so i definitely think this
area should get some serious thought.

i was thinking it wouldnt be a queue-based system. instead, the UDP
notifcations are received and that is it (growl can forget about the
sending application at that point). if a user clicks on a
notification, the callback is fired. if it is a url callback, it is
easy enough to handle, and if it is a desktop/local app callback, that
app is then passed back the appropriate message (this implementation
could be platform-specific, as long as the callback indicator was
generic). something in the callback indicator could identify which
window/app to send the notification to, so there is no need to keep
any queue of information. that also means that if the user doesnt
click on the notification, no more memory/processing is held/required.

the idea here is that to be cross-platform, NSConnection might not be
available to us poor windows (or linux) folks. in order for an app to
have a common way to fire notifications across platforms would be
nice, and i definitely like the idea of 'eating our own dogfood'.
plus, it puts networked/internet apps on the same 'level' as desktop
apps (in other words, they arent limited by a different or more
restrictive protocol - they can do everything that a desktop app can
do).

anyway, that proposal was just a first draft and obvisouly needs
everyone elses input, but i really think that having a single data
format for all types of apps (local/network/internet) and not relying
on platform specific functions (NSConnection) will truly make this a
powerful cross-platform protocol.

On Aug 4, 2008, at 10:16 PM, Peter Hosey wrote:

Is there JSON for AIR?

Chris

AIR runs WebKit internally, so it should have full JSON/javascript
support. i also found this snippet on their site:

"A very limited form of eval() is also available after load, but
restricted to evaluating object literals and constants, which
basically means you can use it for strict JSON notation but not
generation of arbitrary code. "

On Aug 4, 9:47 pm, Chris Forsythe <ch...@growl.info> wrote:

On Aug 5, 2008, at 12:47 AM, Chris Forsythe wrote:

corelib [1] provides JSON serialization as well as MD5/SHA1 hashing. :)

-Evan

[1] http://code.google.com/p/as3corelib/

PGP.sig < 1K Download

On Aug 5, 2008, at 12:39 AM, briandunnington wrote:

The more I think about it, the more I like JSON for this; it strikes a  
balance between writing our own markup language and the verbosity of  
XML.

C++/Win32: JSON Spirit: http://www.codeproject.com/KB/recipes/JSON_Spirit.aspx
Linux: M's JSON parser http://sourceforge.net/projects/mjson/
Ruby, Perl, and Python parsers exist, as well.

I see two possible approaches, which I describe explicitly to help  
clarify the discussion above:

  1. We keep a connection open after a notification is sent; the Growl  
server reuses this connection to send a callback (clicked, closed,  
timed out, etc.) if it is still open when the callback happens.

  2. The notification can optionally include "contact me" information,  
with IP address, port, and context (identifying information, like  
Growl's clickContext), or other directions such as a URL.  If  
included, the server will attempt to send back the desired information  
when it happens.  I don't understand Brian's comments about  
identifying a window/app combination, but I assume that's because it  
has to do with how this would work in Windows.

(1) seems more straightforward and doesn't require the client to  
implement a listener and parser. If the client doesn't want such  
information, it can just close the socket after the write is complete.

(2) is more probably robust, especially in the case that a  
notification is 'sticky' and so is closed or clicked at a time distant  
to the time sent.  It's also more complex for the notifying client,  
which needs to implement a listener.

I don't think we should maintain a single connection from client to  
server from registration onward.  Making connections is typically  
quite cheap, and the far more of an application's time is typically  
spent not sending notifications as compared to sending them.

Currently, Growl does not provide for any way for a notification to be  
targeted to a network destination.  Networking in Growl is used to  
forward notifications which occur on the local machine to other  
machines.  I don't see any reason to switch to using the network  
protocol from standard Growl applications instead of using  
NSConnection; however, certainly we will want local notifications to  
be displayed seamlessly so that applications running on platforms  
without access to the Growl Application Bridge can use the networking  
API easily.

An application, in any language, which sent Growl network  
notifications directly, would be both useful as a test harness for  
this protocol and useful in general.  I don't think this is a  
capability we would build into Growl, as it doesn't make sense for 99%  
of applications which implement Growl to want to notify over the  
network rather than locally.

In other words, the networking protocol should be a full citizen.  I  
think that's a discussion entirely separate from whether Growl  
Application Bridge should change to use the networking protocol for  
Cocoa applications.

Cheers,
Evan

PGP.sig < 1K Download

On Aug 05, 2008, at 13:53:19, Evan Schoenberg wrote:

The problem I have with JSON (and, to an extent, XML) is having to  
receive and parse the entire notification before you can process it.

Consider the case of a notification server that can't handle images.  
With the MIME-like protocol, it could receive a notification like this:

        NOTIFY Download succeeded
        Growl-Protocol-Version: 1.0
        Application: GrowlSafari
        Title: Download succeeded
        Payloads: Description Image
        Description-Length: 41
        Image-Length: 1048576

        File: Growl-1.2.dmg
        Location: ~/Downloads

And it would stop—that is, close the connection and post the  
notification—as soon as it's finished reading the description. After  
all, it doesn't need the image if it's not going to display it. This  
would save bandwidth on the receiving computer (think of places like  
the UK, where internet service is often charged by the minute) as well  
as the sending computer (may be a shared host with a bandwidth cap).

(For that matter, it could stop reading after “Application:” if it  
finds that that notification for that application is turned off. Even  
greater savings!)

JSON doesn't allow this. You have to either receive the image whether  
you can use it or not, or have something like a URL that allows you to  
request it separately. XML allows it, but you have to undergo the pain  
of a stream-based parser, so it's an unpleasant choice.

And I'm not a fan of putting the image behind a URL. It adds  
complexity to both sides: One side, the receiver, must either parse  
the URL or have something that can handle the URL for it; the other  
side, the notifier, must also run a server to serve the resource  
(e.g., image) specified by the URL.

The only reason I can think of for using a URL is that it allows you  
to not get the image if you don't need it—and the MIME-like protocol  
allows that as well, while not requiring anything more than Growl  
already does (no server on the notifying end and no URL-retrieval  
machinery on the receiving end).

On Aug 5, 2008, at 6:09 PM, Peter Hosey wrote:

I don't know of any such notification server, nor do I envision  
developing one. That doesn't at all invalidate the value of your  
proposal, though - see below.

This would also be quite nice if the notification could include a  
unique name or perhaps a hash for the image... and the receiving  
server could choose to cache images and not re-download them.

A stream-based parser really isn't that big a deal.... and if you  
don't want to take advantage of this possibility, you can always use a  
more straightforward all-at-once parser.

Of course, for the stream-based parser for XML to be any savings in  
terms of bandwidth, you'd need to specify that the image must be the  
last thing to be sent, noting that anything sent after the image may,  
at the server's option, be ignored.  That's a pretty nasty violation  
of how XML should work.

I envisioned this more likely being used in a setting like the Gears  
Notification API which is intended to notify from web to desktop... I  
don't imagine it would be used preferentially over sending the image  
directly by a desktop app, typically.

Cheers,
Evan

PGP.sig < 1K Download

On Aug 05, 2008, at 15:29:17, Evan Schoenberg wrote:

Growl isn't currently one, but could be. It's possible that we could  
make it ask displays whether they support images—SMS, Speech, and  
current MailMe wouldn't.

Indeed.

I have both used them and written one (LMX). In my experience, it was  
pain. ☺

More importantly, while writing the code isn't *too* hard, I dread  
ever having to read parser-delegate code again. It's spaghetti code,  
necessarily.

Agreed.

Hm, yeah. That's a hard problem.

What about AIR?

On Aug 5, 3:38 pm, Peter Hosey <p...@growl.info> wrote:

the idea of supporting several image formats (http://, data://, file://,
etc) was to allow the optimal transport type for each use case. a web
site sending notifications is already acting as a server and hosting/
serving images, so it is a no brainer to send just the url (instead of
sending the whole image down). displays that dont want the image can
ignore it with minimal overhead. displays that are webkit/browser-
based can use the url as-is and let the rendering engine fetch the
image for them - growl is off the hook completely.

for desktop apps that arent already serving up images or acting as a
server, using http:// probably wouldnt be the best fit. sending the
raw image data might be easier, and in that case, the network hit of
downloading the entire binary blob is negated by the fact that it isnt
going over the wire. or simply pointing to an image on the local file
system (file://) removes the performance hit of sending the binary
data altogether. the end result is flexibility for all different kinds
of notifiying apps.

the idea of some kind of hash to allow for caching is great. even if
it were not explicity passed, the growl receiver could generate the
hash based on the url/data and use that to identify duplicates. one
less thing for the notifying app to generate/track/etc.

i do like the idea of the MIME-type format being able to ignore pieces
it doesnt want to deal with. will it be limited though by future
additions to the format? for instance, what if notifications
eventually can send in a sound to play, or a video to play, or
multiple images - suddenly the source order is very important. what if
one notification type wants to display images but doesnt care about
sounds, but another (Speech?) wants to play the sound but not display
the image? which one do we optimize for? maybe that is over thinking
it and we just optimize for the most common case.

i think it will be important to decide early on if local applications
will or will not be using this format. depending on if they are/are
not, then some of the considerations might be removed or more
important to consider based on that criteria (ie: not acting as a
server, but 'bandwidth' is much cheaper; local image support vs. url
based, etc).

On Aug 5, 2008, at 7:14 PM, briandunnington wrote:

Local applications will definitely be using this format, but it may  
not be the only format used by local applications.  Just as the local  
connection in Growl via NSConnection requires no authentication, the  
local loop should be open to local apps for sending without the need  
for authentication or configuration.  One important target platform on  
Mac OS X which will use this, for example, is Adobe AIR, which can't  
access Growl directly but can easily send 'network' notifications to  
the local instance.

-Evan

PGP.sig < 1K Download