Growl 1.3 changes

[Christopher Forsythe]

Folks,

We're working towards Growl 1.3. 10.7 is going to change things for us, and as such here are the changes coming down the pipe:

1) Growl is going to be put into the Mac App Store. There are multiple reasons for this:

   - This is the trend that we're seeing across the OS X community

   - This will make distribution much easier for us. One of the biggest complaints that I am seeing on Twitter is people complaining about updating. We do listen.

   - This allows us to get rid of the Disk Image entirely.

   - We can get rid of the PKG installer.

   - We no longer have to maintain Sparkle.

   - For most folks this will make Growl much easier to install and keep Growl up to date.

   - This move also leads to making Growl a much easier application to find.

   - There's more, but that's enough for this list.

2) Growl will become an application. This fits into the MAS rules more than anything else we're doing.

3) Anything which does not go into the Mac App Store will be retired. We already know that both GrowlMail and GrowlSafari no longer fit into this category. I fully expect that GrowlTunes and HardwareGrowler will continue in the Mac App Store. growlnotify should as well, but if it does not we'll evaluate our options there.

   Do not expect any further releases of GrowlMail or GrowlSafari. This is only in bold so that it's easier to see. This should not be unexpected to those who use GrowlMail already, since most of you know that it breaks with every Apple Mail update. That is simply not something we wish to keep up with. Going to the Mac App Store for distribution seals the fate of anything considered more or less a "hack".

4) Growl itself will become 10.7+. 10.6 and below will not be supported in 1.3. 10.7 does not cost a lot of money and we feel that in the long run that by supporting 10.6 and 10.7, it would be harder to push forward with Growl development.

   - Note: The framework will not be 10.7+, it will support previous frameworks so that Developers only need to include one framework.

5) Growl-WithInstaller.framework is going away.

6) We're changing the communication path to GNTP from NSDNC and DO. Applications which continue to use DO or NSDNC will get a line in the Console asking users to contact them to update their Growl framework. Since there is no other real way to communicate this change to Application Developers, we feel that this is the best way to inform them. If someone has a better idea here, please let us know.

All of these changes will take effect as soon as the mercurial repository is put back up. We have a technical difficulty there, but it should be resolved by Monday.

Also, keep in mind that we are looking for more Developers, and that these are not all of the changes coming.

Feel free to reply here or to talk to us on irc on freenode at #growl.

Chris

[Christopher Forsythe]

On Thu, Jun 23, 2011 at 4:37 PM, Christopher Forsythe <ch...@growl.info> wrote:

Folks,

We're working towards Growl 1.3. 10.7 is going to change things for us, and as such here are the changes coming down the pipe:

1) Growl is going to be put into the Mac App Store. There are multiple reasons for this:

   - This is the trend that we're seeing across the OS X community

   - This will make distribution much easier for us. One of the biggest complaints that I am seeing on Twitter is people complaining about updating. We do listen.

   - This allows us to get rid of the Disk Image entirely.

   - We can get rid of the PKG installer.

   - We no longer have to maintain Sparkle.

   - For most folks this will make Growl much easier to install and keep Growl up to date.

   - This move also leads to making Growl a much easier application to find.

   - There's more, but that's enough for this list.

2) Growl will become an application. This fits into the MAS rules more than anything else we're doing.

3) Anything which does not go into the Mac App Store will be retired. We already know that both GrowlMail and GrowlSafari no longer fit into this category. I fully expect that GrowlTunes and HardwareGrowler will continue in the Mac App Store. growlnotify should as well, but if it does not we'll evaluate our options there.

   Do not expect any further releases of GrowlMail or GrowlSafari. This is only in bold so that it's easier to see. This should not be unexpected to those who use GrowlMail already, since most of you know that it breaks with every Apple Mail update. That is simply not something we wish to keep up with. Going to the Mac App Store for distribution seals the fate of anything considered more or less a "hack".

4) Growl itself will become 10.7+. 10.6 and below will not be supported in 1.3. 10.7 does not cost a lot of money and we feel that in the long run that by supporting 10.6 and 10.7, it would be harder to push forward with Growl development.

   - Note: The framework will not be 10.7+, it will support previous frameworks so that Developers only need to include one framework.

One correction here. It will support previous OS X versions, not previous frameworks.

Chris

[TJ Luoma]

Am I correct in assuming that growlctl will cease to work?

If so, I would hope that a replacement would be considered. Being able
to check Growl's status, start, stop, and restart it in scripts is
very handy.

[Christopher Forsythe]

We're intending for growlnotify to continue working, so I don't see why growlctl would stop working either.

We'll have to figure it out though, it may not work immediately at the time of release.

Chris 

[Peter Hosey]

On Jul 6, 2011, at 15:51:50, Christopher Forsythe wrote:
> We're intending for growlnotify to continue working, so I don't see why growlctl would stop working either.

I'm pretty sure growlctl relied on the existence of a prefpane, so it will stop working when we replace the prefpane with an application.

[Christopher Forsythe]

But that doesn't mean we can't change it to make it work with the .app instead.

 

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

[Peter Hosey]

On Jul 6, 2011, at 16:03:56, Christopher Forsythe wrote:
> But that doesn't mean we can't change it to make it work with the .app instead.

So we're going to reincarnate it, then? We killed it off a long time ago, at your insistence.

(If so: Yay! I've always loved growlctl and continued to use it.)

[Christopher Forsythe]

I'm not opposed to having a set of small utilities that help scripters out. I'm just not ok with us spending time on things that we don't have time to spend.

If it's easy to make it work, I'm not opposed.

Chris 

[Neal Horman]

Will the new implementation still support the network udp protocol interface ?

[Peter Hosey]

On Jul 6, 2011, at 19:30:17, Neal Horman wrote:
> Will the new implementation still support the network udp protocol interface ?

Our plan is for Growl 1.3 to support both network protocols it always has supported, plus GNTP, and for Growl 2.0 to kill off all the old protocols—including the UDP one—leaving only GNTP.

[Neal Horman]

[Christopher Forsythe]

That's not correct. UDP goes in 1.3, GNTP and the local GAB method will be there. When 2.0 hits, GAB goes and GNTP is used full time for local. GNTP will also be available for local in 1.3.

UDP has been gone for a while now in the dev repo.

Chris 

[Christopher Forsythe]

On Wed, Jul 6, 2011 at 10:24 PM, Christopher Forsythe <ch...@growl.info> wrote:

On Wed, Jul 6, 2011 at 9:31 PM, Peter Hosey <p...@growl.info> wrote:

On Jul 6, 2011, at 19:30:17, Neal Horman wrote:
> Will the new implementation still support the network udp protocol interface ?

Our plan is for Growl 1.3 to support both network protocols it always has supported, plus GNTP, and for Growl 2.0 to kill off all the old protocols—including the UDP one—leaving only GNTP.

That's not correct. UDP goes in 1.3, GNTP and the local GAB method will be there. When 2.0 hits, GAB goes and GNTP is used full time for local. GNTP will also be available for local in 1.3.

UDP has been gone for a while now in the dev repo.

Also, keep in mind that because Peter had to stick around in the 1.2.x stuff, he was likely not aware of the networking change here.

Chris

[ravedog]

On Jun 23, 2:37 pm, Christopher Forsythe <ch...@growl.info> wrote:

> 3) Anything which does not go into the Mac App Store will be retired. We
> already know that both GrowlMail and GrowlSafari no longer fit into this
> category. I fully expect that GrowlTunes and HardwareGrowler will continue
> in the Mac App Store. growlnotify should as well, but if it does not we'll
> evaluate our options there.
>

>    *Do not expect any further releases of GrowlMail or GrowlSafari*. This is

> only in bold so that it's easier to see. This should not be unexpected to
> those who use GrowlMail already, since most of you know that it breaks with
> every Apple Mail update. That is simply not something we wish to keep up
> with. Going to the Mac App Store for distribution seals the fate of anything
> considered more or less a "hack".

> Chris

What is the logic behind killing GrowlMail and Growl Safari other than
they are plugins for Apple apps. DO you have to kill them to gain
entrance into the store?

Also, will it still be fully AppleScriptable and have the same
dictionary?

[Peter Hosey]

On Jul 7, 2011, at 00:00:09, ravedog wrote:
> What is the logic behind killing GrowlMail and Growl Safari other than they are plugins for Apple apps. DO you have to kill them to gain entrance into the store?

Growl could get into the store regardless of whether we kill GrowlMail and GrowlSafari.

GrowlMail has been a terrible support burden, as much work to maintain as all of our other products combined. GrowlSafari is fragile internally, so while it hasn't caused us many headaches *yet*, it's only a matter of time.

So, we're killing both of them. This will free up the time we'll need to make all the necessary changes to Growl and leave us plenty of time in the future to maintain all of our surviving products.

> Also, will it still be fully AppleScriptable and have the same dictionary?

That's the plan.

[Dylan Ryan]

Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are? If I think I can handle it, I'll take full responsibility for getting things done promptly and keeping it alive for as long as I can. (In all likelihood, I'll just be building my own versions from source if it dies anyway, so I may as well help the project out instead of being selfish about it).

I am less interested in handling Growl-Safari, as I personally do not use it much and given what you just said, it sounds beyond my ability. Though as long as it isn't a major headache, I can handle minor changes to it (that is, I am willing to keep it alive for as long as my skill allows me to, if people are interested).

Dylan

[Christopher Forsythe]

On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <dylan...@gmail.com> wrote:

Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

GrowlMail source is freely available, you may maintain it on your own.

 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are?

Check the release notes and tickets, those are the best things to look at.

 

If I think I can handle it, I'll take full responsibility for getting things done promptly and keeping it alive for as long as I can. (In all likelihood, I'll just be building my own versions from source if it dies anyway, so I may as well help the project out instead of being selfish about it).

The problem is that then GrowlMail becomes the only thing we ship that is still a distraction. In four months say you don't want to do this anymore, then we have to kill it yet again.

 

I am less interested in handling Growl-Safari, as I personally do not use it much and given what you just said, it sounds beyond my ability. Though as long as it isn't a major headache, I can handle minor changes to it (that is, I am willing to keep it alive for as long as my skill allows me to, if people are interested).

I'd say take on what you like.

We haven't sent the official email about the details of GrowlMail being retired yet, please wait for that first.

Chris

[Christopher Forsythe]

On Thu, Jul 7, 2011 at 2:00 AM, ravedog <rav...@gmail.com> wrote:

On Jun 23, 2:37 pm, Christopher Forsythe <ch...@growl.info> wrote:

> 3) Anything which does not go into the Mac App Store will be retired. We
> already know that both GrowlMail and GrowlSafari no longer fit into this
> category. I fully expect that GrowlTunes and HardwareGrowler will continue
> in the Mac App Store. growlnotify should as well, but if it does not we'll
> evaluate our options there.
>
>    *Do not expect any further releases of GrowlMail or GrowlSafari*. This is
> only in bold so that it's easier to see. This should not be unexpected to
> those who use GrowlMail already, since most of you know that it breaks with
> every Apple Mail update. That is simply not something we wish to keep up
> with. Going to the Mac App Store for distribution seals the fate of anything
> considered more or less a "hack".

> Chris

What is the logic behind killing GrowlMail and Growl Safari other than
they are plugins for Apple apps.

They are distractions causing Growl updates to lag behind by dramatic amounts of time, which is no longer acceptable or maintainable imho.

 

DO you have to kill them to gain
entrance into the store?

For them, yes. For Growl, no.

 

Also, will it still be fully AppleScriptable and have the same
dictionary?

Applescriptable, yes. Same dictionary.. maybe? One of our devs was looking into the click handler stuff, so maybe it'll be more robust. We're not killing Applescript, where is this rumor coming from?

Chris

[ravedog]

On Jul 7, 12:55 am, Christopher Forsythe <ch...@growl.info> wrote:

> > long as it *isn't* a major headache, I can handle minor changes to it

> > (that is, I am willing to keep it alive for as long as my skill allows me
> > to, if people are interested).
>
> I'd say take on what you like.
>
> We haven't sent the official email about the details of GrowlMail being
> retired yet, please wait for that first.
>
> Chris
>
>
>
> > Dylan
>
> > On Jul 7, 2011, at 12:03 AM, Peter Hosey wrote:
>
> > On Jul 7, 2011, at 00:00:09, ravedog wrote:
>
> > What is the logic behind killing GrowlMail and Growl Safari other than they
> > are plugins for Apple apps. DO you have to kill them to gain entrance into
> > the store?
>
> > Growl could get into the store regardless of whether we kill GrowlMail and
> > GrowlSafari.
>
> > GrowlMail has been a terrible support burden, as much work to maintain as
> > all of our other products combined. GrowlSafari is fragile internally, so
> > while it hasn't caused us many headaches *yet*, it's only a matter of time.
>
> > So, we're killing both of them. This will free up the time we'll need to
> > make all the necessary changes to Growl and leave us plenty of time in the
> > future to maintain all of our surviving products.

makes sense. just sad. I can wrote Applescripts to do it I guess.

>
> > Also, will it still be fully AppleScriptable and have the same dictionary?
>
> > That's the plan.
>

Awesome on the AppleScript (thats how I use growl)...

I forgot to ask... will Prowl work?

[ravedog]

YOu know you can just write a mail rule using applescript and growl -
it would do exactly the same thing as the plug in.

[Christopher Forsythe]

There are some minor differences, mostly due to the fact that the applescript api lacks clickback support I believe.

Chris

[Dylan Ryan]

On Jul 7, 2011, at 12:55 AM, Christopher Forsythe wrote:

On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <dylan...@gmail.com> wrote:

Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

GrowlMail source is freely available, you may maintain it on your own.

I know, but I'd rather keep it "official" for more people to be able to find. I could make my own and host it (probably on dropbox since that's the easiest), but very few people would find it. Though if I did and you could link to it, that'd work too. I just don't want to maintain it online if the majority of growl users have no easy way to find it. I'd maintain it for myself regardless since I use it, but doing testing for other than my configuration is something I'd only do if I know more than a handful of people can find it.

 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are?

Check the release notes and tickets, those are the best things to look at.

 

I did. For system updates forcing growlmail updates, all I see are scattered 1- or 2-line changes in the changelogs that look like they take all of 2 minutes (plus build/upload time) and could be trivially automated so that it's just a matter of running a "fixGrowlMail" script and having a bundle ready. Add in some (also easily automated) testing on a variety of systems, and I am not seeing anything that would take more than an hour tops per minor system update, with possibly more considerable changes for major system updates. Since you say that it is the most time-consuming part of maintenance, I am assuming there must be a lot more than this, but I am not seeing it with a cursory glance at the 'logs. It doesn't help that over half the links on the growlmail changelog go to a non-public repo (http://growl.info/hg/growl-development/) so I have to delete the -development from the URL to see them. 

Looking at the open growlmail tickets, they all look either minor or else things that I can certainly try my hand at. (I might start chipping away at them shortly, just to see if my expectations match reality)

Basically, from what I can see, the known required maintenance (at system updates) looks minimal, and for the most part, growlmail works now. So, I can certainly handle trivial maintenance duties, and can try to tackle other bugs. Of course, it's possible I'm being horribly naive about it, but the bare minimum job of keeping it working as well as it works now is something I can (and will) definitely do. 

If I think I can handle it, I'll take full responsibility for getting things done promptly and keeping it alive for as long as I can. (In all likelihood, I'll just be building my own versions from source if it dies anyway, so I may as well help the project out instead of being selfish about it).

The problem is that then GrowlMail becomes the only thing we ship that is still a distraction. In four months say you don't want to do this anymore, then we have to kill it yet again.

Not likely to be a problem. Barring any catastrophes, I'm willing to maintain it forever, if only because I use it and will want it fixed for me. Now, granted, I could get hit by a bus tomorrow, but other than that, I'll be keeping it running at least for myself for as long as I can anyway. If I can keep it going for everyone who uses it and keep it readily available/findable, I'm more than willing to do so.

 

I am less interested in handling Growl-Safari, as I personally do not use it much and given what you just said, it sounds beyond my ability. Though as long as it isn't a major headache, I can handle minor changes to it (that is, I am willing to keep it alive for as long as my skill allows me to, if people are interested).

I'd say take on what you like.

We haven't sent the official email about the details of GrowlMail being retired yet, please wait for that first.

Fair enough. Just putting it out there that I'm willing to take it on, along with all the support burden. 

[Dylan Ryan]

Exactly. With growlmail, clicking the notification opens the message (which lets you reply and marks it as read). With an applescript, clicking it just closes it. 

[Christopher Forsythe]

So in other words if we get clickback working then there's no need for GrowlMail? ;)

Chris

[Christopher Forsythe]

On Thu, Jul 7, 2011 at 3:36 AM, Dylan Ryan <dylan...@gmail.com> wrote:

On Jul 7, 2011, at 12:55 AM, Christopher Forsythe wrote:

On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <dylan...@gmail.com> wrote:

Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

GrowlMail source is freely available, you may maintain it on your own.

I know, but I'd rather keep it "official" for more people to be able to find. I could make my own and host it (probably on dropbox since that's the easiest), but very few people would find it. Though if I did and you could link to it, that'd work too. I just don't want to maintain it online if the majority of growl users have no easy way to find it. I'd maintain it for myself regardless since I use it, but doing testing for other than my configuration is something I'd only do if I know more than a handful of people can find it.

 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are?

Check the release notes and tickets, those are the best things to look at.

 

I did. For system updates forcing growlmail updates, all I see are scattered 1- or 2-line changes in the changelogs that look like they take all of 2 minutes (plus build/upload time) and could be trivially automated so that it's just a matter of running a "fixGrowlMail" script and having a bundle ready. Add in some (also easily automated) testing on a variety of systems, and I am not seeing anything that would take more than an hour tops per minor system update, with possibly more considerable changes for major system updates.

There's a lot of problems with just mental state switching between Growl and GrowlMail. Part of the problem is that since this is all not really supported by Apple, we feel it's necessary to test the plugin for quite a while before providing an update. There's a certain responsibility there.

 

Since you say that it is the most time-consuming part of maintenance, I am assuming there must be a lot more than this, but I am not seeing it with a cursory glance at the 'logs. It doesn't help that over half the links on the growlmail changelog go to a non-public repo (http://growl.info/hg/growl-development/) so I have to delete the -development from the URL to see them. 

That's offline temporarily until 10.7 comes out to avoid nda violations.

[Dylan Ryan]

Assuming that everything else worked (getting the right picture for the sender, all the other right info, etc), yeah, that'd be enough for me. When I tested adding a simple applescript, it notified a good half-second faster than growlmail, too (though that might not apply once you have an applescript that gets all the same info as growlmail)

[George]

Could you not have growl in the app store and some plugins such as
GrowlMail etc. out of the app store much like Boom does? There is no
*legal* reason why that won't work plus you have a working example of
other software that already does that. Yes you will have to still
maintain a pkg installer for the out of store plugins and the process
might be a wee bit more complex that you like but my point is that you
don't have to dump the already existing code just because Apple won't
let you put it on the App Store.

Anyway, either way I'm and will be a huge fan and an active user so
thanks for all the work guys.

[Dylan Ryan]

On Jul 7, 2011, at 2:06 AM, Christopher Forsythe wrote:

On Thu, Jul 7, 2011 at 3:36 AM, Dylan Ryan <dylan...@gmail.com> wrote:

On Jul 7, 2011, at 12:55 AM, Christopher Forsythe wrote:

On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <dylan...@gmail.com> wrote:

Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

GrowlMail source is freely available, you may maintain it on your own.

I know, but I'd rather keep it "official" for more people to be able to find. I could make my own and host it (probably on dropbox since that's the easiest), but very few people would find it. Though if I did and you could link to it, that'd work too. I just don't want to maintain it online if the majority of growl users have no easy way to find it. I'd maintain it for myself regardless since I use it, but doing testing for other than my configuration is something I'd only do if I know more than a handful of people can find it.

 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are?

Check the release notes and tickets, those are the best things to look at.

 

I did. For system updates forcing growlmail updates, all I see are scattered 1- or 2-line changes in the changelogs that look like they take all of 2 minutes (plus build/upload time) and could be trivially automated so that it's just a matter of running a "fixGrowlMail" script and having a bundle ready. Add in some (also easily automated) testing on a variety of systems, and I am not seeing anything that would take more than an hour tops per minor system update, with possibly more considerable changes for major system updates.

There's a lot of problems with just mental state switching between Growl and GrowlMail. Part of the problem is that since this is all not really supported by Apple, we feel it's necessary to test the plugin for quite a while before providing an update. There's a certain responsibility there.

I know, but I see it slightly differently. From my perspective, if there is a widespread problem with just adding the new UUIDs, odds are I'll notice it quickly after making a change. That is, extensive testing isn't necessary for a widespread problem, cursory testing will almost certainly find it. And if there is a highly specific problem, odds are no amount of testing I can do will find it because I probably don't have access to the right combination of hardware and software to trigger it anyway. That is, extensive testing isn't helpful because odds are I do not have the right equipment to trigger it, so why waste time trying to do the impossible? So rather than testing for a week knowing that odds are I won't find anything, to me it seems more logical to update the UUIDs, do a quick "does this work?" check on as much hardware as I can, then release it as a "potentially unstable" version an hour or two after a system update. Anyone who can't wait can use it and provide the large testing platform that I don't have access to, but the vast majority of people will likely find that it works because it passed the "works on my hardware so probably works in most places" test. This seems better than waiting a week or more to test, not finding anything, releasing a "this is stable" version, and having the same people that would have caught the problem in the "potentially unstable" version catch it anyway and report it. It cuts a week or more off the wait time for people willing to take a risk (makes people happy), means less problems on versions that are expected to be stable (makes people happy), etc. 

Granted, for general software, that is probably the worst possible method you could think of for pushing updates, but for such a small bundle that does just one thing (and does it well), it seems that it would be generally helpful. There aren't a lot of features to test, so a fairly basic "Does it work?" type check is close to exhaustive. Especially given the track record. As I said, as far as I have seen, I've never had a problem simply adding the UUIDs, so that has a track record of working (or I am lucky and have a blessed hardware/software combo that just happens to always work). Obviously, anything could change at any time, but I still think an unstable branch that updates fast and should work but might not, and a stable branch that almost always does work but takes time to update (think Chrome, etc) leads to getting updates out quicker, and if an unstable branch breaks for some people for a few days, well, that's why it's called unstable.

Hopefully that makes sense :) 

 

Since you say that it is the most time-consuming part of maintenance, I am assuming there must be a lot more than this, but I am not seeing it with a cursory glance at the 'logs. It doesn't help that over half the links on the growlmail changelog go to a non-public repo (http://growl.info/hg/growl-development/) so I have to delete the -development from the URL to see them. 

That's offline temporarily until 10.7 comes out to avoid nda violations.

Makes sense. But some of the links point to the (stable) hg and some to the dev. Would be better just to point them all to stable since I was able to delete -development and get to what looks like the right changesets in every case.

[Richard Hamilton]

On Thu, Jul 7, 2011 at 6:11 AM, Dylan Ryan <dylan...@gmail.com> wrote:

[...]

I know, but I see it slightly differently. From my perspective, if there is a widespread problem with just adding the new UUIDs, odds are I'll notice it quickly after making a change. That is, extensive testing isn't necessary for a widespread problem, cursory testing will almost certainly find it. And if there is a highly specific problem, odds are no amount of testing I can do will find it because I probably don't have access to the right combination of hardware and software to trigger it anyway. That is, extensive testing isn't helpful because odds are I do not have the right equipment to trigger it, so why waste time trying to do the impossible? So rather than testing for a week knowing that odds are I won't find anything, to me it seems more logical to update the UUIDs, do a quick "does this work?" check on as much hardware as I can, then release it as a "potentially unstable" version an hour or two after a system update. Anyone who can't wait can use it and provide the large testing platform that I don't have access to, but the vast majority of people will likely find that it works because it passed the "works on my hardware so probably works in most places" test. This seems better than waiting a week or more to test, not finding anything, releasing a "this is stable" version, and having the same people that would have caught the problem in the "potentially unstable" version catch it anyway and report it. It cuts a week or more off the wait time for people willing to take a risk (makes people happy), means less problems on versions that are expected to be stable (makes people happy), etc. 

Granted, for general software, that is probably the worst possible method you could think of for pushing updates, but for such a small bundle that does just one thing (and does it well), it seems that it would be generally helpful. There aren't a lot of features to test, so a fairly basic "Does it work?" type check is close to exhaustive. Especially given the track record. As I said, as far as I have seen, I've never had a problem simply adding the UUIDs, so that has a track record of working (or I am lucky and have a blessed hardware/software combo that just happens to always work). Obviously, anything could change at any time, but I still think an unstable branch that updates fast and should work but might not, and a stable branch that almost always does work but takes time to update (think Chrome, etc) leads to getting updates out quicker, and if an unstable branch breaks for some people for a few days, well, that's why it's called unstable.

Hopefully that makes sense :)

Does anyone know and feel free to comment whether, aside from UUIDs, the current GrowlMail works (at least to the quick "does this work" standard) with the 10.7 GM that's available to paid-up devs?   In other words, it's one thing if it probably has a couple years life left in it at a minimum.  But it it would need a lot more for 10.7 (and remember, Mail _is_ said to be changing, so I wouldn't care to bet on a guess either way), then maybe some alternative would be better.

Either way, clickback with AppleScript would be great, if possible.  And for those of us challenged by anything as "friendly" as AppleScript (give me C++ anytime over that!), some sample rules to approximate GrowlMail behavior corresponding to different preference settings would be a big help, particularly if having someone else keep GrowlMail alive turns out not to be as straightforward as adding UUIDs, running some quick checks, and repackaging it.

[i.aten...@gmail.com]

Attached is a start.
there are some reference applescripts in /Library/Scripts/Mail Scripts/Rule Actions for the mail bit
and current growl applescript docs here: http://growl.info/documentation/applescript-support.php

as for how to do stuff in applescript:
yes it can be frustrating at times.
good example; if one wanted to get rid of the <email address> bit at the end of the sender text in the above example, this is the best i’ve found so far: http://stackoverflow.com/questions/1716440/applescript-index-of-substring-in-string
:/

Josh

[Gary L. Gray]

On Jul 7, 2011, at 10:14 AM, i.aten...@gmail.com wrote:

> Attached is a start.
> there are some reference applescripts in /Library/Scripts/Mail Scripts/Rule Actions for the mail bit
> and current growl applescript docs here: http://growl.info/documentation/applescript-support.php

This feels like a stupid question, but how do I implement it?

Gary

[Peter Hosey]

On Jul 7, 2011, at 01:36:35, Dylan Ryan wrote:
> It doesn't help that over half the links on the growlmail changelog go to a non-public repo (http://growl.info/hg/growl-development/) so I have to delete the -development from the URL to see them.

Oops. That was a temporary measure while those changesets weren't in the stable repo (/hg/growl/). I meant to come back and update them to go to stable, and have now done so. Thanks for pointing this out.

The website updates every 15 minutes, so the change will take effect at 8:00 AM PDT.

[Peter Hosey]

On Jul 7, 2011, at 02:46:57, George wrote:
> Could you not have growl in the app store and some plugins such as GrowlMail etc. out of the app store much like Boom does?

Growl and GrowlMail have nothing to do with each other besides a common set of developers. Killing GrowlMail and moving Growl to the App Store are unrelated actions.

> … my point is that you don't have to dump the already existing code just because Apple won't let you put it on the App Store.

The App Store has nothing to do with our killing GrowlMail. We were already planning to kill it before we decided to put Growl into the App Store.

We're killing GrowlMail because it's a terrible support burden. That's the only reason.

[i.aten...@gmail.com]

You mean have it run?
Mail -> Preferences -> Rules
add a new rule
set up which mails you want it to be run for (‘every message’ will run it on everything)
set the action to ‘run applescript’ and select the script, wherever you saved it

If you mean writing/editing scripts:
/Applications/Utilities/Applescript Editor.app

[Gary L. Gray]

The former. Thank you.

All the best,
Gary

[Neal Horman]

em... ok, just so I understand clearly....

1.2.x currently has the udp protocol ? which I have made extensive use of, but is old, and obscurely documented here.

1.3.x won't have the udp protocol, but will have GNTP ?
Not sure where it is documented as there are no references on the web site, which is 1.2.x centric and has no road map at all.

2.x won't have either ?

So there will be no way to have local network based notifications ?

[Peter Hosey]

On Jul 7, 2011, at 09:29:37, Neal Horman wrote:
> em... ok, just so I understand clearly....
>
> 1.2.x currently has the udp protocol ? which I have made extensive use of, but is old, and obscurely documented here.
>
> 1.3.x won't have the udp protocol, but will have GNTP ?

Yes.

> Not sure where it is documented as there are no references on the web site, which is 1.2.x centric and has no road map at all.

The roadmap is on our Google Code project site:

http://code.google.com/p/growl/wiki/RoadMap

We haven't updated it for our App Store plans yet, though.

> 2.x won't have either ?
>
> So there will be no way to have local network based notifications ?

Incorrect. GNTP is the new protocol for 1.3 and all future versions.

[Rudy Richter]

I'm going to be putting GrowlMail and the UUID patcher application up
under my github account this weekend. 10.7 related changes will get
pushed when 10.7 is publicly available.

-rudy

On Jul 7, 6:39 am, Richard Hamilton <rlham...@gmail.com> wrote:

> On Thu, Jul 7, 2011 at 6:11 AM, Dylan Ryan <dylantr...@gmail.com> wrote:
> > [...]

> > I know, but I see it slightly differently. From my perspective, *if* there

> > is a widespread problem with just adding the new UUIDs, odds are I'll notice
> > it quickly after making a change. That is, extensive testing isn't necessary
> > for a widespread problem, cursory testing will almost certainly find it. And
> > if there is a highly specific problem, odds are no amount of testing I can
> > do will find it because I probably don't have access to the right
> > combination of hardware and software to trigger it anyway. That is,
> > extensive testing isn't helpful because odds are I do not have the right
> > equipment to trigger it, so why waste time trying to do the impossible? So
> > rather than testing for a week knowing that odds are I won't find anything,
> > to me it seems more logical to update the UUIDs, do a quick "does this
> > work?" check on as much hardware as I can, then release it as a "potentially
> > unstable" version an hour or two after a system update. Anyone who can't
> > wait can use it and provide the large testing platform that I don't have
> > access to, but the vast majority of people will likely find that it works
> > because it passed the "works on my hardware so probably works in most
> > places" test. This seems better than waiting a week or more to test, not

> > finding anything, releasing a "this *is* stable" version, and having the

> > same people that would have caught the problem in the "potentially unstable"
> > version catch it anyway and report it. It cuts a week or more off the wait
> > time for people willing to take a risk (makes people happy), means less
> > problems on versions that are expected to be stable (makes people happy),
> > etc.
>

> > Granted, for general software, that is probably the *worst* possible

> > method you could think of for pushing updates, but for such a small bundle
> > that does just one thing (and does it well), it seems that it would be
> > generally helpful. There aren't a lot of features to test, so a fairly basic
> > "Does it work?" type check is close to exhaustive. Especially given the
> > track record. As I said, as far as I have seen, I've never had a problem
> > simply adding the UUIDs, so that has a track record of working (or I am
> > lucky and have a blessed hardware/software combo that just happens to always
> > work). Obviously, anything could change at any time, but I still think an

> > unstable branch that updates fast and *should* work but might not, and a

[Rudy Richter]

We're currently considering including Prowl with the release, but
worst case it would continue to function as it does now.

-rudy

[Rudy Richter]

The critical fact that you're missing here is that you are running an
additional app. GrowlMail and subsequently Mail.app are not the owner
of the windows that pop up on your screen telling you that you've got
new mail. There is an application sitting inside the Growl
PreferencePane that is putting those up on your screen called
GrowlHelperApp. The app as will be available from the MacAppStore will
combine the functionality of 3 separate binaries into a single
process.

-rudy

[Peter Hosey]

On Jul 7, 2011, at 10:01:14, Rudy Richter wrote:
> The critical fact that you're missing here is that you are running an additional app. GrowlMail and subsequently Mail.app are not the owner of the windows that pop up on your screen telling you that you've got new mail. There is an application sitting inside the Growl PreferencePane that is putting those up on your screen called GrowlHelperApp. The app as will be available from the MacAppStore will combine the functionality of 3 separate binaries into a single process.

To clarify, the application that we will put in the Mac App Store is Growl prefpane + GrowlHelperApp + GrowlMenu (the menu-bar item).

GrowlMail is an entirely separate product, a plug-in for Mail.

GrowlMail creates the notifications and sends them on to Growl; Growl displays them.

[Richard Johnson]

On Thu, Jun 23, 2011 at 04:37:05PM -0500, Christopher Forsythe wrote:
> Folks,
>
> We're working towards Growl 1.3. 10.7 is going to change things for us, and
> as such here are the changes coming down the pipe:
>
> 1) Growl is going to be put into the Mac App Store. There are multiple
> reasons for this:

The Mac App Store is perfect for individuals who are allowed to and want to
create an Apple ID for using it and who have direct admin account access.

However, for those of us who manage enterprise and remote installations
(scientific field projects, rural schools), going solely with the store is
a problem. We very often won't have users on site with admin privs, or the
ability/legal authority to sign up with the Mac App Store.

Even Apple is backing down on the Mac OS X 10.7 Lion distribution being
solely via the Mac App Store. They've been forced to offer enterprise-
grade downloadable installers, for use off-line.

Chris, I deeply respect that you're developing Growl. You should take it
in a direction that you feel necessary, supportable, and useful. I find it
useful, personally, as is and with the planned distribution and updating
via the Mac App Store.

I'd just like to plead as well for keeping Growl available and useful for
the current users who don't match your particular use case. This means
some ability to install Growl without direct Mac App Store access, even if
the installer is downloaded from the Mac App Store before being distributed
via puppet or the like. If this can't be done, then that will end Growl
support for such systems. You may consider the Growl developer support
benefits of losing that user base to be a good trade-off, but I would
consider it a loss.

Thanks for at least considering the need.

[Neal Horman]

Thanks for the quick and clear response.

Looking at the current code in the GoogleCode, it appears to be over year old, and there is nothing there for GNTP.
Following the clones trail, there are some changes in hiimerik-lrgrowl that appears to have some GNTP stuff, and also appears to be really old.

Looking through some of the "Issues" tickets, it appears that somewhere hidden in a secret place there is a separate developers repository that holds all of the new "good" stuff, and GC is merely a published code repository that is 1.2.x based.

So, how does someone actually get involved with Trunk, Tags, and Branch (to use a svn'ism) code base so as to be able to get a fix on the state of the project ?

One of the issues in tracker (or wiki, don't remember now) states that GNTP needs docs.
Well I'm might be interested in trying to participate in that to be able to gain an understanding of the protocol so that I can re-write my network server interface to do GNTP notifications, but I don't know where to go from here....

help, left stranded on the side of the road!

[Christopher Forsythe]

My understanding is that you can "buy" once and then copy wherever you want.

Chris

[Christopher Forsythe]

We had to lock the repo down until 10.7 comes out (not the gm to devs, the official release) to avoid nda violations.

The gntp spec is here:

http://www.growlforwindows.com/gfw/help/gntp.aspx

I'm working on gathering a list of available resources for gntp, there are tons of implementations in multiple different languages already. 

Keep in mind we're not going to be implementing encryption due to our concern of violating US export laws. Until we get a clear go ahead on that, encryption will not be there.

Chris

 

--
You received this message because you are subscribed to the Google Groups "Growl Discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/growldiscuss/-/CWo1Zw4FTWoJ.

[Rudy Richter]

That said, we're not opposed to new developers working on Growl. In
fact, if you're skilled or looking to cut your teeth on an established
codebase we'd like to hear from you on the growl development list.
We're pretty solidly along on the tasks for getting Growl into the
MAS, but after we submit we've got a laundry list of modernization,
code reduction and a complete UI overhaul on the configuration side of
things planned. By putting Growl in the MacAppStore and reducing the
dearth of crufty (there are still 10.3 references) legacy code the app
as a whole will be much easier to maintain, work on, and allow us to
add a whole bunch of really useful user facing features to Growl.

-rudy

On Jul 7, 2:14 pm, Christopher Forsythe <ch...@growl.info> wrote:

> On Thu, Jul 7, 2011 at 1:11 PM, Neal Horman <nkhor...@gmail.com> wrote:
>
> > On Thursday, July 7, 2011 11:40:53 AM UTC-5, Peter Hosey wrote:
>
> >> On Jul 7, 2011, at 09:29:37, Neal Horman wrote:
> >> > em... ok, just so I understand clearly....
>
> >> > 1.2.x currently has the udp protocol ? which I have made extensive use
> >> of, but is old, and obscurely documented here.
>
> >> > 1.3.x won't have the udp protocol, but will have GNTP ?
>
> >> Yes.
>
> >> > Not sure where it is documented as there are no references on the web
> >> site, which is 1.2.x centric and has no road map at all.
>
> >> The roadmap is on our Google Code project site:
>

> >>http://code.google.com/p/**growl/wiki/RoadMap<http://code.google.com/p/growl/wiki/RoadMap>

[Dylan Ryan]

No, I'm not missing that point. In fact, that was exactly my point. Growl is an app. I would rather not have it running (I don't like any programs running in the background if I can help it). However, I really like growlmail, so because of that, I'll let growl run. As a side-effect, I get other nice-but-not-vital notifications from other programs. But without growlmail, I have no reason to keep using growl. Regardless of whether the app is inside a prefpane or delivered via the MAS or something else entirely, it's still a (admittedly amazingly resource-light) app that I'd rather not have running. Don't get me wrong, I love growl and I'll be sad if I end up removing it, I just am a little OCD about running apps. If I do not actively use something, I don't let it run. Growl is one of the few passive apps that I let run, and only because of GrowlMail. 

--
You received this message because you are subscribed to the Google Groups "Growl Discuss" group.

[Christopher Forsythe]

Wait for the email for GrowlMail then. There are going to be some next steps in there. The Growl project is just no longer going to maintain it or provide it at all.

Chris

[Neal Horman]

On Thursday, July 7, 2011 1:14:39 PM UTC-5, Chris Forsythe wrote:

On Thu, Jul 7, 2011 at 1:11 PM, Neal Horman <nkho...@gmail.com> wrote:

On Thursday, July 7, 2011 11:40:53 AM UTC-5, Peter Hosey wrote:

On Jul 7, 2011, at 09:29:37, Neal Horman wrote:
> em... ok, just so I understand clearly....
>
> 1.2.x currently has the udp protocol ? which I have made extensive use of, but is old, and obscurely documented here.
>
> 1.3.x won't have the udp protocol, but will have GNTP ?

Yes.

> Not sure where it is documented as there are no references on the web site, which is 1.2.x centric and has no road map at all.

The roadmap is on our Google Code project site:

http://code.google.com/p/growl/wiki/RoadMap

We haven't updated it for our App Store plans yet, though.

> 2.x won't have either ?
>
> So there will be no way to have local network based notifications ?

Incorrect. GNTP is the new protocol for 1.3 and all future versions.

Thanks for the quick and clear response.

Looking at the current code in the GoogleCode, it appears to be over year old, and there is nothing there for GNTP.
Following the clones trail, there are some changes in hiimerik-lrgrowl that appears to have some GNTP stuff, and also appears to be really old.

Looking through some of the "Issues" tickets, it appears that somewhere hidden in a secret place there is a separate developers repository that holds all of the new "good" stuff, and GC is merely a published code repository that is 1.2.x based.

So, how does someone actually get involved with Trunk, Tags, and Branch (to use a svn'ism) code base so as to be able to get a fix on the state of the project ?

One of the issues in tracker (or wiki, don't remember now) states that GNTP needs docs.
Well I'm might be interested in trying to participate in that to be able to gain an understanding of the protocol so that I can re-write my network server interface to do GNTP notifications, but I don't know where to go from here....

help, left stranded on the side of the road!

We had to lock the repo down until 10.7 comes out (not the gm to devs, the official release) to avoid nda violations.

This makes sense now since I've also signed the NDA.

The gntp spec is here:

http://www.growlforwindows.com/gfw/help/gntp.aspx

Interesting that it is a GfW spec.
I think I remember seeing this a few years back, but payed no attention to it because it wasn't officially supported by Growl, and then I implemented the upd protocol.
One of the things that GNTP doesn't take into consideration is broadcast based notifications because it's tcp centric, which udp handles by nature.
This could possibly be handled by taking advantage of Bonjour notifications, assuming that they are implemented by the growl notification application clients, but if there are a lot of them, then there is a lot more network traffic, and a lot more work on the notification producer side to keep track of all the clients (sockets, passwords, etc...) which is why the upd protocol was so nice and easy for me to implement in my notification producer server application because it was a simple broadcast message.

What is the current relationship between Growl and GfW ?
 

I'm working on gathering a list of available resources for gntp, there are tons of implementations in multiple different languages already. 

I'll be interested to see that.
 

[Rudy Richter]

You'll probably want to switch to the Rudy Richter distribution of
GrowlMail then. It will make use of the new framework being developed
for the Growl 1.3 release. Hopefully you like the Smoke display style
though, as the framework will only include that one style. In that
particular case GrowlMail/Mail.app will be the app producing the
window with your notification.

-rudy

[Peter Hosey]

On Jul 7, 2011, at 12:12:01, Neal Horman wrote:
> Interesting that it is a GfW spec.

GfW hosts it, but it was jointly developed between us and them, with developers of all the other notification systems of the time also present (they were welcome to pipe up but ended up not saying much).

> What is the current relationship between Growl and GfW ?

Separate projects sharing a name.

[Neal Horman]

On Thursday, July 7, 2011 1:33:09 PM UTC-5, Rudy Richter wrote:

That said, we're not opposed to new developers working on Growl. In
fact, if you're skilled or looking to cut your teeth on an established
codebase we'd like to hear from you on the growl development list.
We're pretty solidly along on the tasks for getting Growl into the
MAS, but after we submit we've got a laundry list of modernization,
code reduction and a complete UI overhaul on the configuration side of
things planned.  By putting Growl in the MacAppStore and reducing the
dearth of crufty (there are still 10.3 references) legacy code the app
as a whole will be much easier to maintain, work on, and allow us to
add a whole bunch of really useful user facing features to Growl.

-rudy

I appreciate that.
I'm relatively new to ObjectiveC.
I've built a couple of iPhone apps for personal use that make heavy use of Apple Push Notification Service, and I know that I don't have a real good grasp for how to use the language constructs well, nor do I understand many of the frameworks.
So I don't know that I'd be a good candidate for working on such a well established code base.
But I will keep this in mind, it is my style of application to work on. (communication / backend tool centric) 

[Dylan Ryan]

I am not sure I understand. If Mail is what is making the notifications, would they still be aware of other growl messages? Or would running that and growl simultaneously result in the two overlapping each other due to not being able to communicate?

[Peter Hosey]

On Jul 7, 2011, at 12:27:45, Dylan Ryan wrote:
> If Mail

(GrowlMail)

> … is what is making the notifications, would they still be aware of other growl messages? Or would running that and growl simultaneously result in the two overlapping each other due to not being able to communicate?

We've anticipated this. The plan is for the framework to use its own built-in mini-Growl if and only if Growl is not installed. If Growl is installed, the framework will defer to the installed Growl.

[Chris Forsythe]

You're a perfect candidate for gaining knowledge by working on Growl. :)

Chris

--
You received this message because you are subscribed to the Google Groups "Growl Discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/growldiscuss/-/Ykxc1DBm1FkJ.

[Dylan Ryan]

Ok, that makes much more sense. Thanks for clarifying!

[Chris @ fullphat]

On Jul 7, 8:20 pm, Peter Hosey <p...@growl.info> wrote:
> On Jul 7, 2011, at 12:12:01, Neal Horman wrote:
>
> > Interesting that it is a GfW spec.
>
> GfW hosts it, but it was jointly developed between us and them, with developers of all the other notification systems of the time also present (they were welcome to pipe up but ended up not saying much).
>

That's generally true but we (Snarl) had our own TCP-based protocol in
place at the time and were working on support for Growl's UDP
implementation. We proposed our implementation (SNP) and were quite
strongly shouted down by the Growl team, hence we retreated to a safe
distance.

My personal take is that GNTP is still a rather bloated protocol,
being based around a mime format rather than something more current
such as XML. Since then Snarl's own protocol has developed
significantly and will continue to with support for encryption and
mDNS on the way.

Anyhow, we still support Growl/UDP, GNTP and our own protocol.

[Peter Hosey]

On Jul 8, 2011, at 07:14:06, Chris @ fullphat wrote:
> On Jul 7, 8:20 pm, Peter Hosey <p...@growl.info> wrote:
>> On Jul 7, 2011, at 12:12:01, Neal Horman wrote:
>>
>>> Interesting that it is a GfW spec.
>>
>> GfW hosts it, but it was jointly developed between us and them, with developers of all the other notification systems of the time also present (they were welcome to pipe up but ended up not saying much).
>
> That's generally true but we (Snarl) had our own TCP-based protocol in place at the time and were working on support for Growl's UDP implementation. We proposed our implementation (SNP) and were quite strongly shouted down by the Growl team, hence we retreated to a safe distance.

What? I searched my mail archive and couldn't find anything about SNP. When and where was this?

> My personal take is that GNTP is still a rather bloated protocol, being based around a mime format rather than something more current such as XML.

My opinion at the time was that XML would have been more bloated, particularly for visually reading; I proposed using or emulating MIME so that it would be simpler, not more complex.

[Chris Forsythe]

On Jul 8, 2011, at 10:32 AM, Peter Hosey <p...@growl.info> wrote:

> On Jul 8, 2011, at 07:14:06, Chris @ fullphat wrote:
>> On Jul 7, 8:20 pm, Peter Hosey <p...@growl.info> wrote:
>>> On Jul 7, 2011, at 12:12:01, Neal Horman wrote:
>>>
>>>> Interesting that it is a GfW spec.
>>>
>>> GfW hosts it, but it was jointly developed between us and them, with developers of all the other notification systems of the time also present (they were welcome to pipe up but ended up not saying much).
>>
>> That's generally true but we (Snarl) had our own TCP-based protocol in place at the time and were working on support for Growl's UDP implementation. We proposed our implementation (SNP) and were quite strongly shouted down by the Growl team, hence we retreated to a safe distance.
>
> What? I searched my mail archive and couldn't find anything about SNP. When and where was this?
>

I don't remember this either.

>> My personal take is that GNTP is still a rather bloated protocol, being based around a mime format rather than something more current such as XML.
>
> My opinion at the time was that XML would have been more bloated, particularly for visually reading; I proposed using or emulating MIME so that it would be simpler, not more complex.
>

> --
> You received this message because you are subscribed to the Google Groups "Growl Discuss" group.

[Christopher Forsythe]

I just searched my email archives, and the only other email that I have from you (besides this one) is the email you sent to Peter and myself accusing us of favoring GfW over Snarl. You conceded that you were in fact not correct. I don't remember any other contact from you guys at all. Peter doesn't and he's been on the project for years. I'll ask Rudy who has been on since 2004.

Let me be clear here. We're not interested in supporting both GNTP and SNP. We've opted for GNTP, because to be honest when we were looking for a new protocol the GfW guys stepped up and I didn't hear anything from you guys about it even though I did try contacting you.

Snarl has been around a very long time, and I appreciate that it's inspired by our project. That said, it is very inappropriate to essentially come to us right before release in this manner. At the very least you could have picked the correct group (development, not discuss).

Like I said before in the email, when I get back to work on the website (should start next Tuesday) then I want to link to different implementations and discuss their differences in a way that makes the most sense for end users. End users don't care if there are 2 or 10 protocols, they just want it to work. GNTP works for us, so I don't see us changing. If you have a problem with it, we've all been using the development list as a sort of official discussion place for the protocol, please bring it up there. I would appreciate if you did that *after* 1.3 is released though.

Chris

[Chris @ fullphat]

On Jul 8, 4:45 pm, Chris Forsythe <ch...@growl.info> wrote:
> On Jul 8, 2011, at 10:32 AM, Peter Hosey <p...@growl.info> wrote:
>
> > On Jul 8, 2011, at 07:14:06, Chris @ fullphat wrote:
> >> On Jul 7, 8:20 pm, Peter Hosey <p...@growl.info> wrote:
> >>> On Jul 7, 2011, at 12:12:01, Neal Horman wrote:
>
> >>>> Interesting that it is a GfW spec.
>
> >>> GfW hosts it, but it was jointly developed between us and them, with developers of all the other notification systems of the time also present (they were welcome to pipe up but ended up not saying much).
>
> >> That's generally true but we (Snarl) had our own TCP-based protocol in place at the time and were working on support for Growl's UDP implementation.  We proposed our implementation (SNP) and were quite strongly shouted down by the Growl team, hence we retreated to a safe distance.
>
> > What? I searched my mail archive and couldn't find anything about SNP. When and where was this?
>
> I don't remember this either.

I'll see if I can find them but I didn't want for this to be a "well,
he said, so I said" conversation; I just wanted to defend Snarl's
position at the time as your comments didn't match my recollection.

>
>
>
>
>
>
>
> >> My personal take is that GNTP is still a rather bloated protocol, being based around a mime format rather than something more current such as XML.
>
> > My opinion at the time was that XML would have been more bloated, particularly for visually reading; I proposed using or emulating MIME so that it would be simpler, not more complex.
>

I think that was my point at the time: I couldn't (and still can't)
see the point in it being visually readable when it's a machine-to-
machine protocol. IMO excess message content is to be avoided -
especially when encryption is involved as it (a) makes it visually
unreadable anyway, (b) typically increases the length of a message and
(c) usually can't be accelerated.

It's academic I know, but the specification for SNP 3.0 is on our Wiki
in case you're interested in reading it.

[ShadowBottle]

Ouch, too bad to hear about growlmail, particularly since Mail.app has
such a difficult time notifying users that they have new mail -
besides remembering to glance at the dock to make sure, that is.

Growlmail was the only way to get new mail notifications if you wanted
to use Mail.app.

Maybe Apple will actually fix Mail.app so it finally dings again, or
at least maybe for 50% of the time - still won't be as effective as
Growlmail though. After six years though, I don't find that likely.

Oh well, here's to looking to unofficial releases of Growl and/or
Growlmail!

[Derik]

On Thu, Jul 21, 2011 at 7:56 AM, ShadowBottle <shadow...@gmail.com> wrote:
> Growlmail was the only way to get new mail notifications if you wanted
> to use Mail.app.

Nothing against GrowlMail, but I've been a long time user of Herald,
which although isn't Growl, does rather nice notifications.

http://www.macupdate.com/app/mac/32744/herald

I'd link to the website for the product itself, but it's currently down.

[Christopher Forsythe]

I have updated the GrowlMail page to reflect the changes happening with that.

http://growl.info/growlmail/

Chris

 

[Jack]

Can GrowlMail 1.2.5 be updated to support Mac OS X 10.6.8? I'm looking
forward to Lion but will not upgrade for some time, as many of my
applications are not compatible. Thank you!

[Christopher Forsythe]

1.2.5 is the last version of GrowlMail that we'll be putting out. There is a list for GrowlMail that we are not a part of that you can ask this question on:

http://growl.info/growlmail/

Chris