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?
> In August, I will be implementing a TCP-based networking protocol for > Growl and will be continuing to improve networking in general. >=20 > What TCP-based networking protocol? That's where this email and you, > dear reader, come in. >=20 > 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 wit= h > (1) and (2), should be straightforward for a wide variety of platforms > to use. >=20 > Peter and I discussed the protocol a bit off-list already.
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?
> I initially suggested an XML-based protocol, as XML is easy to read (fo= r > 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> >=20 > 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)
This could probably be easily rectified by something like xmlrpc over htt= ps.
> His counter-suggestion was something similar to MIME headers, like this= : >=20 > Action: Notification > Title: Something happened! > Description: This thing happened, and I thought you should know. > Image: 103908 > <103908 bytes of image data>
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.
> Any thoughts or preferences for one approach versus the other?
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.
> 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?
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.
On Aug 03, 2008, at 18:08:11, Evan Schoenberg wrote:
> Also, the full [XML] document must be parsed for it to make sense.
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.
> (Peter, please clarify if I misunderstood any of that)
Aside from the above, you nailed it.
> Any thoughts or preferences for one approach versus the other?
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.
> 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?
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.
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.
> Has anyone considered JSON? It's a much lighter protocol than XML > is (in bytes transmitted at least) and is very widely used already.
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?
> Secondly, how about simply sending a URL to the image to use rather > than trying to send the image itself?
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.
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:
> 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?
On Aug 04, 2008, at 00:18:54, Vinay Venkatesh wrote:
> 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.
Sounds relevant to this thread. Would you mind inviting him to this list?
> 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.
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.
> As far as passwords go, it could just as easily be Public/Private > Key encrypted, …
Interesting. Advantages/disadvantages over plain hashing?
> … where a key is specified for a host after the initial registration > with the server.
>> As far as passwords go, it could just as easily be Public/Private >> Key encrypted, …
> Interesting. Advantages/disadvantages over plain hashing?
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?
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.
> 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.
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.
> 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:
>> 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.
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:
> 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 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:
> >> 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.
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.
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.
> - 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).
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.
> - callbacks are specified in one of several formats, similar to > image data.
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.
> you said this should be TCP based, but are you really just trying to > figure out the data format?
At this time, yes.
> i mean, could the same data format also be sent over UDP if desired > (and the Growl app supported it)?
Sure. (See below.)
> i think that a standard data format is the important piece here.
Agreed.
> 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).
I don't think we've decided that yet.
> in a thread in the Growl [discuss] group, i think someone said that > they envisioned this protocol eventually replacing both the > exisiting TCP and UDP protocols - is that still the goal?
That was me, and yes, that's still what I want.
> if so, does that mean this protocol will be used for network > notifications,
Yup.
> 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).
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.
On Aug 4, 8:16 pm, Peter Hosey <p...@growl.info> wrote:
> 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.)
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.
> 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.
agreed - the details are not as important as getting the concepts at
this point.
> Good point. I'm really not sure how to handle callbacks.
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.
> 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.
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.
> 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.
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 04, 2008, at 10:56:43, briandunnington 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 agree that they should be, but are they? :)
> - Is there a JSON parser for Windows? > - Is there a JSON parser for Linux?
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:
> On Aug 4, 2008, at 10:16 PM, Peter Hosey wrote:
>> On Aug 04, 2008, at 10:56:43, briandunnington 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 agree that they should be, but are they? :)
>> - Is there a JSON parser for Windows? >> - Is there a JSON parser for Linux?
> Is there JSON for AIR?
corelib [1] provides JSON serialization as well as MD5/SHA1 hashing. :)
>> Good point. I'm really not sure how to handle callbacks.
> 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. >> 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.
> 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.
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.
>> 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.
> 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
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.
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).
> 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.
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.
> And it would stop—that is, close the connection and post the > notification—as soon as it's finished reading the description.
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.
> (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.
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.
> 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).
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.
On Aug 05, 2008, at 15:29:17, Evan Schoenberg wrote:
> I don't know of any such notification server, nor do I envision > developing one.
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.
> 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.
Indeed.
> A stream-based parser really isn't that big a deal....
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.
> 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.
Agreed.
>> And I'm not a fan of putting the image behind a URL. …
> I envisioned this more likely being used in a setting like the Gears > Notification API which is intended to notify from web to desktop...
On Aug 5, 3:38 pm, Peter Hosey <p...@growl.info> wrote:
> On Aug 05, 2008, at 15:29:17, Evan Schoenberg wrote:
> >> And I'm not a fan of putting the image behind a URL. …
> > I envisioned this more likely being used in a setting like the Gears
> > Notification API which is intended to notify from web to desktop...
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:
> 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).
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.
|
