GNTP coalescing

[Brian Dunnington]

Hey guys. I noticed a bug in your Google Code issue tracker related to
coalesing: http://code.google.com/p/growl/issues/detail?id=381&q=coalescing&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20BlockedOn%20Summary%20Product

Daniel said that Growl is using the Notification-Coalescing-ID from
*both* notifications to determine the coalescing, as opposed to using
the Notification-ID from the first notification and the
Notification-Coalescing-ID from the second like the GNTP spec calls
for. Turns out Growl for Windows does the same thing, and in thinking
about it, the implemented behavior makes more sense than the
documented behavior. I wrote a bit about it in the bug report, but
wanted to post here as well to prod any discussion.

What do you guys think about changing the spec? I dont know of any
implementations of the documented method, so it hopefully wouldnt
break too much.

[Christopher Forsythe]

I'm not opposed to changing the spec, but it might be a good idea to make any current necessary changes if we're going to change it. i.e. if you want to change 5 things, let's talk about all of those and do it in one fell swoop.

Chris

--
You received this message because you are subscribed to the Google Groups "Growl Development" group.
To post to this group, send email to growl-de...@googlegroups.com.
To unsubscribe from this group, send email to growl-developm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growl-development?hl=en.

[Brian Dunnington]

That seems like a good idea. The only other things I know that need to
be addressed are:

1. Security of non-encrypted notifications that supply a password hash
as discussed here:
http://groups.google.com/group/growldiscuss/browse_thread/thread/64b2a8a97320284e/df3a24dc4fc71d1f
- though the fix for this might be complicated

2. Socket re-use. No implementor that I know of (Growl, GfW, or Snarl)
currently supports socket re-use completely, and none of the client
libraries that I am aware of currently support it either, so I vote
for ditching it. It changes no working implementations, cleans up the
spec a bit, and makes compliant implementations easier.

I think Chris from Snarl had a few ideas/suggestions as well, so maybe
he will chime in.

[Christopher Forsythe]

I'll post a blog post for a request for comment on our protocol some time this weekend, and point to this google group as the place to discuss it to see if anyone else has a good idea. I'd like to get the Snarl guys at least involved if they are still on the list as well. I believe these are the only items that have been brought up so far though.

Chris