I'm writing a little app which will forward notifications to a central computer running Growl for Windows via GNTP. The GNTP documentation appears to state that simply sending a NOTIFY packet is sufficient, but the same document also indicates that applications must be registered before generating notifications.
So, should my app send a REGISTER and a NOTIFY each time, or is just sending a NOTIFY sufficient?
On Sat, 29 Oct 2011 14:33:52 +0100, Phat Bob <phatbob1...@gmail.com> wrote:
> Hello
> I'm writing a little app which will forward notifications to a central > computer running Growl for Windows via GNTP. The GNTP documentation > appears to state that simply sending a NOTIFY packet is sufficient, but > the same document also indicates that applications must be registered > before generating notifications.
The spec is clear - "An application MUST first REGISTER with the notification system."
So it depends on what you mean by forwarding notifications.
If your app forwards notifications generated by other apps on the computer, then you need to forward their registrations as well as their notifications - otherwise they won't have registered on the remote system. If your app generates new notifications which you send to another system then you MUST register these notifications before you send them.
> So, should my app send a REGISTER and a NOTIFY each time, or is just > sending a NOTIFY sufficient?
You should not send a register and notify each time. If you generate notifications then you should register them once (usually when the app starts) before you send any, rather than each time. If you are passing on notifications from other sources, then you also need to send on their registrations.
> On Sat, 29 Oct 2011 14:33:52 +0100, Phat Bob <phatbob1...@gmail.com> wrote:
>> Hello
>> I'm writing a little app which will forward notifications to a central computer running Growl for Windows via GNTP. The GNTP documentation appears to state that simply sending a NOTIFY packet is sufficient, but the same document also indicates that applications must be registered before generating notifications.
> The spec is clear - "An application MUST first REGISTER with the notification system."
> So it depends on what you mean by forwarding notifications.
> If your app forwards notifications generated by other apps on the computer, then you need to forward their registrations as well as their notifications - otherwise they won't have registered on the remote system. > If your app generates new notifications which you send to another system then you MUST register these notifications before you send them.
>> So, should my app send a REGISTER and a NOTIFY each time, or is just sending a NOTIFY sufficient?
> You should not send a register and notify each time. > If you generate notifications then you should register them once (usually when the app starts) before you send any, rather than each time. > If you are passing on notifications from other sources, then you also need to send on their registrations.
The problem is that the remote computer will reboot frequently so will I need to register each time or is one registration sufficient (that is, the registration persists)?
> -- > You received this message because you are subscribed to the Google Groups "growl for windows" group. > To post to this group, send email to growl-for-windows@googlegroups.com. > To unsubscribe from this group, send email to growl-for-windows+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
On Sat, 29 Oct 2011 15:26:31 +0100, Phat Bob <phatbob1...@gmail.com> wrote:
> On 29 Oct 2011, at 15:10, "Alan Montgomery" > <A...@alanmontgomery.orangehome.co.uk> wrote:
>> On Sat, 29 Oct 2011 14:33:52 +0100, Phat Bob <phatbob1...@gmail.com> >> wrote:
>>> Hello
>>> I'm writing a little app which will forward notifications to a central >>> computer running Growl for Windows via GNTP. The GNTP documentation >>> appears to state that simply sending a NOTIFY packet is sufficient, >>> but the same document also indicates that applications must be >>> registered before generating notifications.
>> The spec is clear - "An application MUST first REGISTER with the >> notification system."
>> So it depends on what you mean by forwarding notifications.
>> If your app forwards notifications generated by other apps on the >> computer, then you need to forward their registrations as well as their >> notifications - otherwise they won't have registered on the remote >> system. >> If your app generates new notifications which you send to another >> system then you MUST register these notifications before you send them.
>>> So, should my app send a REGISTER and a NOTIFY each time, or is just >>> sending a NOTIFY sufficient?
>> You should not send a register and notify each time. >> If you generate notifications then you should register them once >> (usually when the app starts) before you send any, rather than each >> time. >> If you are passing on notifications from other sources, then you also >> need to send on their registrations.
> The problem is that the remote computer will reboot frequently so will > I need to register each time or is one registration sufficient (that is, > the registration persists)?
You can assume the registration is persistent. The spec refers to registering with the system - not with the instance of the server. Also if the registration isn't persistent, then the server could restart between sending the registration and the immediately following notification.
>> -- >> You received this message because you are subscribed to the Google >> Groups "growl for windows" group. >> To post to this group, send email to growl-for-windows@googlegroups.com. >> To unsubscribe from this group, send email to >> growl-for-windows+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/growl-for-windows?hl=en.
> On Sat, 29 Oct 2011 15:26:31 +0100, Phat Bob <phatbob1...@gmail.com> wrote:
>> On 29 Oct 2011, at 15:10, "Alan Montgomery" <A...@alanmontgomery.orangehome.co.uk> wrote:
>>> On Sat, 29 Oct 2011 14:33:52 +0100, Phat Bob <phatbob1...@gmail.com> wrote:
>>>> Hello
>>>> I'm writing a little app which will forward notifications to a central computer running Growl for Windows via GNTP. The GNTP documentation appears to state that simply sending a NOTIFY packet is sufficient, but the same document also indicates that applications must be registered before generating notifications.
>>> The spec is clear - "An application MUST first REGISTER with the notification system."
>>> So it depends on what you mean by forwarding notifications.
>>> If your app forwards notifications generated by other apps on the computer, then you need to forward their registrations as well as their notifications - otherwise they won't have registered on the remote system. >>> If your app generates new notifications which you send to another system then you MUST register these notifications before you send them.
>>>> So, should my app send a REGISTER and a NOTIFY each time, or is just sending a NOTIFY sufficient?
>>> You should not send a register and notify each time. >>> If you generate notifications then you should register them once (usually when the app starts) before you send any, rather than each time. >>> If you are passing on notifications from other sources, then you also need to send on their registrations.
>> The problem is that the remote computer will reboot frequently so will >> I need to register each time or is one registration sufficient (that is, the registration persists)?
> You can assume the registration is persistent. > The spec refers to registering with the system - not with the instance of the server. Also if the registration isn't persistent, then the server could restart between sending the registration and the immediately following notification.
>>> -- >>> You received this message because you are subscribed to the Google Groups "growl for windows" group. >>> To post to this group, send email to growl-for-windows@googlegroups.com. >>> To unsubscribe from this group, send email to growl-for-windows+unsubscribe@googlegroups.com. >>> For more options, visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "growl for windows" group. > To post to this group, send email to growl-for-windows@googlegroups.com. > To unsubscribe from this group, send email to growl-for-windows+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
It is good practice to always send the registration first for the following reasons:
1. The sender do not know for certain that the receiver has the applications registered in GfW, register makes sure that it is. 2. You may have changed number or types of notifications, or icons, in the receiving app, the only way to update this is by a new registration. 3. The receiver may have had the app registered but removed it for any number of reasons (re-installs, removal of app for debugging reasons,and so on). If you assume that it is still registered, you'll encounter an error. 4. It has become a defacto best practise standard, take a look at any of the other libraries and classes out there that handles your growl communications, they all send register first, then the growl itself. 5. It's easier to just send it first. If not, you'd have to keep a record off all receivers, and design an error handler that tries to resend the message with a register first if it fails on the first try (error handler since you cannot expect the receiver to tell you it isn't registered when you send...)
And.. if you build your forwarder / app to use the growl-sending mechanism as a class, you'd have to register a new class instance for each send anyway, so you could with just one line of code extra send a register to the receiving end as well..
On 30 Oct 2011, at 00:59, IanMM <i...@melsom.be> wrote:
> But also..
> It is good practice to always send the registration first for the following reasons:
> 1. The sender do not know for certain that the receiver has the applications registered in GfW, register makes sure that it is.
Yes, this was my main concern.
> 2. You may have changed number or types of notifications, or icons, in the receiving app, the only way to update this is by a new registration. > 3. The receiver may have had the app registered but removed it for any number of reasons (re-installs, removal of app for debugging reasons,and so on). If you assume that it is still registered, you'll encounter an error. > 4. It has become a defacto best practise standard, take a look at any of the other libraries and classes out there that handles your growl communications, they all send register first, then the growl itself.
I'd noticed this myself but it seemed such an overhead I wondered if it was just poor programming
> 5. It's easier to just send it first. If not, you'd have to keep a record off all receivers, and design an error handler that tries to resend the message with a register first if it fails on the first try (error handler since you cannot expect the receiver to tell you it isn't registered when you send...)
> And.. if you build your forwarder / app to use the growl-sending mechanism as a class, you'd have to register a new class instance for each send anyway, so you could with just one line of code extra send a register to the receiving end as well..
Thanks Ian - this makes good sense. Maybe for GNTP/1.1 you could coalesce the NOTIFY and REGISTER directives into a single packet?
I'd like to get involved in GNTP development - I have some other suggestions in that area. Is there a working group?
> -- > You received this message because you are subscribed to the Google Groups "growl for windows" group. > To view this discussion on the web visit https://groups.google.com/d/msg/growl-for-windows/-/2AHNjbfsQtAJ. > To post to this group, send email to growl-for-windows@googlegroups.com. > To unsubscribe from this group, send email to growl-for-windows+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
I'm actually not a growl developer, I have just, i varying degrees been active on this forum. The main growl developer is Brian, who reads here most of the time. Your request of coalescing register & notify may have its merits, But I think brian have to answer you there.
the working group is more or less here:D Just leave your suggestions and they will be discussed and possibly included in the roadmap. There is also a repository somewhere, I forget the link, where you can DL all you need to look into the workings of growl yourself.
On 30 Oct 2011, at 10:28, IanMM <i...@melsom.be> wrote:
> I'm actually not a growl developer, I have just, i varying degrees been active on this forum. The main growl developer is Brian, who reads here most of the time. Your request of coalescing register & notify may have its merits, But I think brian have to answer you there.
> the working group is more or less here:D Just leave your suggestions and they will be discussed and possibly included in the roadmap.
Off the top of my head:
• Support for digitally signing GNTP packets without the need for encryption;
• Ability to unregister an app by specifying zero notification classes (or a specific UNREGISTER) directive as Snarl supports already;
• Insist on the use of the "END" marker to signify the end of a GNTP packet instead of relying on active parsing;
• Firm up some of the "looseness" of GNTP - for example, the fact that GfW allows spurious spaces at the end of application names which means that "My App " is treated the same as "My App";
• Register port 23053 with IANA, or switch to a registered port.
> There is also a repository somewhere, I forget the link, where you can DL all you need to look into the workings of growl yourself. > -- > You received this message because you are subscribed to the Google Groups "growl for windows" group. > To view this discussion on the web visit https://groups.google.com/d/msg/growl-for-windows/-/sAj1nf0zK9gJ. > To post to this group, send email to growl-for-windows@googlegroups.com. > To unsubscribe from this group, send email to growl-for-windows+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
On Sun, 30 Oct 2011 00:59:35 +0100, IanMM <i...@melsom.be> wrote: > But also..
> It is good practice to always send the registration first for the > following > reasons:
> 1. The sender do not know for certain that the receiver has the > applications registered in GfW, register makes sure that it is.
If you cannot trust the server to keep the previous registration then you can't trust it to keep the previous registration even if it is sent immediately before the notification.
> 2. You may have changed number or types of notifications, or icons, in > the > receiving app, the only way to update this is by a new registration.
This is the app's problem - and spamming registrations doesn't solve it. This is most noticeable if you have two different versions of the app running that produce different notifications at the same time. Part of the problem is that G4W takes a registration as de-registering any type not in the new registration - so the registration from the old version removes the new types.
> 3. The receiver may have had the app registered but removed it for any > number of reasons (re-installs, removal of app for debugging reasons,and > so > on). If you assume that it is still registered, you'll encounter an > error.
A registration is needed at some point but not at the notification - except in response to a not registered response.
> 4. It has become a defacto best practise standard, take a look at any of > the other libraries and classes out there that handles your growl > communications, they all send register first, then the growl itself.
It is bad practice - that "everybody" does it doesn't make it good. It reduces the chance of a not-registered error but it doesn't eliminate it. The closest you can get to solving the problem is to resend the registration and the notification in response to a not registered error - all on the same socket (which G4W doesn't support). Here you can be certain the registration is sent to the same instance of the server but you can't be absolutely certain that something else hasn't removed the registration in the very small amount of time between the two resends. It can also significantly increase the volume of network traffic - and some people pay based on data volume, or have capped data volumes (such as people forwarding to a mobile phone - which can be £1 per MB or more).
> 5. It's easier to just send it first. If not, you'd have to keep a record > off all receivers, and design an error handler that tries to resend the > message with a register first if it fails on the first try (error handler > since you cannot expect the receiver to tell you it isn't registered when > you send...)
I don't follow this this. When you send the request you only see one receiver and it WILL tell you if the notification isn't registered. The only time you would have multiple receivers would be if your app is forwarding to multiple servers (i.e. distributing the notification) - in which case how you handle different responses from the different servers is the app's problem.
> And.. if you build your forwarder / app to use the growl-sending > mechanism > as a class, you'd have to register a new class instance for each send > anyway, so you could with just one line of code extra send a register to > the receiving end as well..
If it is a forwarder (i.e. router or bridge) it should forward only the registrations and notifications it receives, and pass back the response it receives as it response. If it is an app (i.e. a client) it should register all its notifications at some point prior to the first notifications. Deciding if this is at installation, or when the app starts up, or immediately before the first notification, is a design issue that depends on the nature of the application and its environment.
> On 30 Oct 2011, at 00:59, IanMM <i...@melsom.be> wrote:
> Thanks Ian - this makes good sense. Maybe for GNTP/1.1 you could > coalesce the NOTIFY and REGISTER directives into a single packet?
You can't do that as they serve different purposes.
The register informs the server what notifications the app can send, and thus allows a user to customise how the server responds to those messages. Without this the server would not know that it could receive a notification until it actually got one, which in turn would mean the user couldn't configure how it was handled until it was first received.
An alternative is to reduce the MUST register requirement to SHOULD register - and leave it as a problem for the server as to how to customise unregistered types and apps. I would probably reduce it to a SHOULD register but also add text saying that the server MAY reject notifications that aren't registered.
> On 30 Oct 2011, at 10:28, IanMM <i...@melsom.be> wrote:
> Off the top of my head:
> • Support for digitally signing GNTP packets without the need for > encryption;
Probably simple to add - all you need is support for the END marker - even if you don't support connection reuse. Then add the signature as optional data on the tail of the END.
> • Ability to unregister an app by specifying zero notification classes > (or a specific UNREGISTER) directive as Snarl supports already;
I suspect at the moment if GfW gets a registration with 0 entries it will effectively unregister. The only use case I can think of is in the uninstall - you can't do it at exit as other apps may be running and you don't want to delete the related configuration except at uninstall.
One issue is that a registration from an app removes the notification types that aren't in the new registration. This can cause issues when two different versions of the same app are running as each one's registration removes any types that only the other uses. Example: if the app version 1 produces A B and C, and version 2 replaces A with D and E - so produces B C D and E. There is no way for A through E to all be registered.
You need a way to remove A once you don't run version 1 - but the current system removes A every time you run Version 2, and D and E every time you run Version 1.
Adding a new UNREGISTER request that can be send from the uninstaller would then allow the server to decide if it wants to delete its entries (so GfW could prompt the user is they want to delete the entries.)
> • Insist on the use of the "END" marker to signify the end of a GNTP > packet instead of relying on active parsing;
Any time you change a spec you end up with the situation where the two programs that are trying to connect work to different versions of the spec - it is generally good to make changes where that doesn't cause a problem. Saying that the server MUST accept the END marker is OK, saying that the client MUST generate it will prevent updated clients talking to old servers, likewise saying that servers must require it will stop old clients talking to new servers. Remember there is no way for the client to query the server as to what version of the spec it is working to.
> • Firm up some of the "looseness" of GNTP - for example, the fact that > GfW allows spurious spaces at the end of application names which means > that "My App " is treated the same as "My App";
Hard to do without knowing where all loose bits are.
Icons - there is no guidance on supported types, nor on suggested sizes. Given the spec doesn't give any way for a client to enquire, nor even a way to find out if the request was rejected because the format wasn't supported, or even because the server couldn't identify the type, there needs to be some guidance.
Uniqueness of IDs - I assume these have to be unique on all messages on servers that receive the notification and unique for all time.
Coalescing - can a notification of a different type, or even from a different app replace a previous notification? Can you specify multiple Notification-Coalescing-IDs to replace multiple previous notifications? This might be desirable if B replaces A and afterwards C replaces B - what happens if a server forwards A and C but not B so that the downstream systems see C as replacing a non-existent B and don't know that B replaced A. Can you replace a subsequent notification? What happens is in the above case notifications B and C if B is delayed in transmission and so arrives after C.
> • Register port 23053 with IANA, or switch to a registered port.
The port is currently unassigned - so no need to switch to a different port.
> Rob
One thing I would like to see added to the spec is a CANCEL command. Currently you can replace one notification with another by specifying a "Notification-Coalescing-ID:". The CANCEL command would have this as a required field and the effect would be to remove the matching notification.
Another is an extra optional header to the REGISTER "Uses-Coalescing <boolean>" this can be set before the list of types to set the default and/or on individual types. When set true it provides a hint to the server (GfW) that is should uses a display that supports coalescing.
Another is improvement to the current mechanism for skipping known resources. The current mechanism of ending the connection once you have all the resources you want doesn't work well if you want to reuse the connection later. Nor does it work well if the message specifies several resources and you only want the last one - there is no way to skip the others. A better way is to have the option of omitting the resource definition from the message and the server would respond with a MISSING_RESOURCE (101) error and a list of resource IDs it wants. The client would then give the resource definitions and the server would give the final response. Older servers would give a 300 error requiring the message to be resent in full.
On 30 Oct 2011, at 16:23, "Alan Montgomery" <A...@alanmontgomery.orangehome.co.uk> wrote:
> On Sun, 30 Oct 2011 00:59:35 +0100, IanMM <i...@melsom.be> wrote:
>> But also..
>> It is good practice to always send the registration first for the following >> reasons:
>> 1. The sender do not know for certain that the receiver has the >> applications registered in GfW, register makes sure that it is.
> If you cannot trust the server to keep the previous registration then you can't trust it to keep the previous registration even if it is sent immediately before the notification.
There has to be a level of common sense applied - the server won't fall over at a moments notice, although it'll be a 24x7 system and thus will be rebooted from time to time.
>> 2. You may have changed number or types of notifications, or icons, in the >> receiving app, the only way to update this is by a new registration.
> This is the app's problem - and spamming registrations doesn't solve it. This is most noticeable if you have two different versions of the app running that produce different notifications at the same time. > Part of the problem is that G4W takes a registration as de-registering any type not in the new registration - so the registration from the old version removes the new types.
Yes, I ran across this limitation in GNTP a while back. At the moment we simply add notification classes as the app develops - it's noted that this isn't ideal.
>> 3. The receiver may have had the app registered but removed it for any >> number of reasons (re-installs, removal of app for debugging reasons,and so >> on). If you assume that it is still registered, you'll encounter an error.
> A registration is needed at some point but not at the notification - except in response to a not registered response.
>> 4. It has become a defacto best practise standard, take a look at any of >> the other libraries and classes out there that handles your growl >> communications, they all send register first, then the growl itself.
> It is bad practice - that "everybody" does it doesn't make it good. It reduces the chance of a not-registered error but it doesn't eliminate it. The closest you can get to solving the problem is to resend the registration and the notification in response to a not registered error - all on the same socket (which G4W doesn't support). Here you can be certain the registration is sent to the same instance of the server but you can't be absolutely certain that something else hasn't removed the registration in the very small amount of time between the two resends. > It can also significantly increase the volume of network traffic - and some people pay based on data volume, or have capped data volumes (such as people forwarding to a mobile phone - which can be £1 per MB or more).
It's ok for us at the moment as this is running on a LAN. Sadly it has prevented us from rolling it out elsewhere due to exactly the issue you describe (ie we're charged by the MB for data sent)
>> 5. It's easier to just send it first. If not, you'd have to keep a record >> off all receivers, and design an error handler that tries to resend the >> message with a register first if it fails on the first try (error handler >> since you cannot expect the receiver to tell you it isn't registered when >> you send...)
> I don't follow this this. > When you send the request you only see one receiver and it WILL tell you if the notification isn't registered. The only time you would have multiple receivers would be if your app is forwarding to multiple servers (i.e. distributing the notification) - in which case how you handle different responses from the different servers is the app's problem.
>> And.. if you build your forwarder / app to use the growl-sending mechanism >> as a class, you'd have to register a new class instance for each send >> anyway, so you could with just one line of code extra send a register to >> the receiving end as well..
> If it is a forwarder (i.e. router or bridge) it should forward only the registrations and notifications it receives, and pass back the response it receives as it response. > If it is an app (i.e. a client) it should register all its notifications at some point prior to the first notifications. Deciding if this is at installation, or when the app starts up, or immediately before the first notification, is a design issue that depends on the nature of the application and its environment.
>> On 30 Oct 2011, at 00:59, IanMM <i...@melsom.be> wrote:
>> Thanks Ian - this makes good sense. Maybe for GNTP/1.1 you could coalesce the NOTIFY and REGISTER directives into a single packet?
> You can't do that as they serve different purposes.
> The register informs the server what notifications the app can send, and thus allows a user to customise how the server responds to those messages. Without this the server would not know that it could receive a notification until it actually got one, which in turn would mean the user couldn't configure how it was handled until it was first received.
While that sounds fine in theory, most apps register on demand and thus the user has no time to configure the class settings before at least one notification happens.
If this is against policy, the GNTP documentation should be updated accordingly; I don't see it as a major issue though. Others might of course.
If the "class bug" is resolved such that classes are combined not replaced, then a NOTIFY could include all the application info, the class the notification belongs to and the notification content with minimum overhead. Using a new directive ("NOTIFYEX" for example) would retain backwards comparability too.
> An alternative is to reduce the MUST register requirement to SHOULD register - and leave it as a problem for the server as to how to customise unregistered types and apps. I would probably reduce it to a SHOULD register but also add text saying that the server MAY reject notifications that aren't registered.
>> On 30 Oct 2011, at 10:28, IanMM <i...@melsom.be> wrote:
>> Off the top of my head:
>> • Support for digitally signing GNTP packets without the need for encryption;
> Probably simple to add - all you need is support for the END marker - even if you don't support connection reuse. Then add the signature as optional data on the tail of the END.
>> • Ability to unregister an app by specifying zero notification classes (or a specific UNREGISTER) directive as Snarl supports already;
> I suspect at the moment if GfW gets a registration with 0 entries it will effectively unregister. The only use case I can think of is in the uninstall - you can't do it at exit as other apps may be running and you don't want to delete the related configuration except at uninstall.
I don't mean for GfW to support it - the GNTP is supposed to be agnostic, right? The Snarl guys use a different registration model (which we prefer actually, but that's not relevant here) and thus this would allow GNTP to support functionality they already provide.
> One issue is that a registration from an app removes the notification types that aren't in the new registration. This can cause issues when two different versions of the same app are running as each one's registration removes any types that only the other uses. > Example: if the app version 1 produces A B and C, and version 2 replaces A with D and E - so produces B C D and E. There is no way for A through E to all be registered.
That's an issue for GfW, not other GNTP clients, to resolve.
> You need a way to remove A once you don't run version 1 - but the current system removes A every time you run Version 2, and D and E every time you run Version 1.
> Adding a new UNREGISTER request that can be send from the uninstaller would then allow the server to decide if it wants to delete its entries (so GfW could prompt the user is they want to delete the entries.)
Precisely
>> • Insist on the use of the "END" marker to signify the end of a GNTP packet instead of relying on active parsing;
> Any time you change a spec you end up with the situation where the two programs that are trying to connect work to different versions of the spec - it is generally good to make changes where that doesn't cause a problem. > Saying that the server MUST accept the END marker is OK, saying that the client MUST generate it will prevent updated clients talking to old servers, likewise saying that servers must require it will stop old clients talking to new servers. Remember there is no way for the client to query the server as to what version of the spec it is working to.
This is all for a future version of GNTP, not the existing one. Clients talking GNTP/1.0 would see no difference.
>> • Firm up some of the "looseness" of GNTP - for example, the fact that GfW allows spurious spaces at the end of application names which means that "My App " is treated the same as "My App";
> Hard to do without knowing where all loose bits are.
> Icons - there is no guidance on supported types, nor on suggested sizes. Given the spec doesn't give any way for a client to enquire, nor even a way to find out if the request was rejected because the format wasn't supported, or even because the server couldn't identify the type, there needs to be some guidance.
> Uniqueness of IDs - I assume these have to be unique on all messages on servers that receive the notification and unique for all time.
> Coalescing - can a notification of a different type, or even from a different app replace a previous notification? Can you specify multiple Notification-Coalescing-IDs to replace multiple previous notifications? This might be desirable if B replaces A and afterwards C replaces B - what
lots of good discussion here, and i am going to chew on all of it a bit, but i wanted to note a few things before i forgot:
1. the registration model of Snarl and Growl are just two different things. In Snarl, i dont believe an app even has to register to send notifications, but if it does, it is more like a 'per-session' type of registration. when the apps closes, it de-registers. In Growl, registrations are permanent and allow a set of persistent user customizations to be associated with an app and its notifications. I wouldnt say the Growl way is better or worse, just different, so when thinking about them, it is important to not get too caught up in how they align.
2. The GNTP spec is not clear on it, but a REGISTER request is *supposed* to replace any existing notification type registrations. During the initial discussion on the spec, that was the consensus on what made the most sense. If an app wants to register just a single new type, they are expected to know what other types they have already registered for. In the case of two versions of the same app wanting to register two different sets of notification types, the onus is on the app to handle its versioning issues, just like it would have to do with any other app-specific settings or data.
3. An UNREGISTER command was deemed unnecessary since a REGISTER completely replaces all existing registrations (removing the need to individually unregister notification types) and so the only use would be for when an app was uninstalled. I can see the case for it there (just to be a good citizen and remove any trace of the app), but I think it was decided that if the app was later re-installed, it would be better to have retained the user's configuration settings for that app. (otherwise, an app could just unregister and reregister itself and wipe out the user's preferences).
4. As for the 'loose handling of spaces', I posted about this on the Snarl forum awhile back - it is actually by design and follows the same rules as other MIME-like protocols. From the HTTP spec, section 4.2: (http://www.ietf.org/rfc/rfc2616.txt) " message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string>
The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS MAY be removed without changing the semantics of the field value."
I updated the GNTP spec to indicate that trailing whitespace should safely be ignored, and I think Chris updated the Snarl implementation to correctly handle the whitespace.
5. a STATUS command was originally proposed which would have taken the application name and returned the list of notification types currently registered. this would have enabled 1) a kind of no-op to check the status of the GNTP receiver (see if it is running) and 2) let the app not have to track which notifications it had already registered. in the end, it was deemed unnecessary since just sending a NOTIFY or REGISTER would provide the same indication of the service's status, and the app should reasonably be expected to track which notifications it had registered.
A lot of these points could be argued either way, and I myself argued the opposing position on several of them. In the end though, it was most important to have an inter-operable spec with a minimum amount of commands to make it as easy as possible for app developers to get up and running. More advanced cases probably stretch the spec a bit more, but I have not yet run into any case that could not be solved using what already exists.
Keep the discussion coming though, I am always glad to hear how folks are using the tools and where the pain points are. There are a few other shortcomings of the v1.0 spec that I have noted myself, but putting out a v1.1 or v2.0 has been a low priority since Growl (on the Mac) just shipped its initial v1.0 support in the past couple of weeks. Getting them up and running on GNTP was step one and changing the spec and potentially breaking existing implementations was not something we wanted to do at the moment. I definitely foresee an updated version though, and all of these ideas will help shape what it looks like.
On Sunday, 30 October 2011 17:23:35 UTC+1, sagji wrote:
> On Sun, 30 Oct 2011 00:59:35 +0100, IanMM <i...@melsom.be> wrote:
> > But also..
> > It is good practice to always send the registration first for the
> > following
> > reasons:
> > 1. The sender do not know for certain that the receiver has the
> > applications registered in GfW, register makes sure that it is.
> If you cannot trust the server to keep the previous registration then you
> can't trust it to keep the previous registration even if it is sent
> immediately before the notification.
The _server_ do not keep any registrations, only the recipient keep them. The server only sends... And yes.. there is a miniscule chance that the recipient may remove the registered app in the very short period between the register and the notification. This however would be due to a software problem on the recipients side, or a user action/error.. So no.. you cannot implicitly trust that the recipient has the app registered at all times.
> > 2. You may have changed number or types of notifications, or icons, in
> > the
> > receiving app, the only way to update this is by a new registration.
> This is the app's problem - and spamming registrations doesn't solve it.
> This is most noticeable if you have two different versions of the app
> running that produce different notifications at the same time.
> Part of the problem is that G4W takes a registration as de-registering any
> type not in the new registration - so the registration from the old
> version removes the new types.
How do you suggest the app on the recieving end should predict how many different types of notifications it should have? or what icons to use? It falls back to default when nothing is given from the server. The number of different types of notifications, and what icons to use is defined by the server, and the apps only way to get updates on this is if the server tells it. This is done by registering.
> > 3. The receiver may have had the app registered but removed it for any
> > number of reasons (re-installs, removal of app for debugging reasons,and
> > so
> > on). If you assume that it is still registered, you'll encounter an
> > error.
> A registration is needed at some point but not at the notification -
> except in response to a not registered response.
The current version of Growl an GNTP do not, as far as I know, support an error message that returns a "not registered" error. It is simply discarder at the recipients side. Much like the tcp-protocol that discards unknown frames..
> > 4. It has become a defacto best practise standard, take a look at any of
> > the other libraries and classes out there that handles your growl
> > communications, they all send register first, then the growl itself.
> It is bad practice - that "everybody" does it doesn't make it good. It
> reduces the chance of a not-registered error but it doesn't eliminate it.
> The closest you can get to solving the problem is to resend the
> registration and the notification in response to a not registered error -
> all on the same socket (which G4W doesn't support). Here you can be
> certain the registration is sent to the same instance of the server but
> you can't be absolutely certain that something else hasn't removed the
> registration in the very small amount of time between the two resends.
> It can also significantly increase the volume of network traffic - and
> some people pay based on data volume, or have capped data volumes (such as
> people forwarding to a mobile phone - which can be £1 per MB or more).
> In percentages, yes (it doubles it from one packet to two), in actual
measurements? Then you'd have to have an ridiculous amount of messages being sent. But if you look at growl usage, most apps and uses are localhost (on same machine) or on the Local Area Network (between a server sending a tasknotif and a PC). Pulling in mobiles is kinda unfair, since those forwardes that does this does it by setting up a percistent connection to a server to poll if there has been sent a message or not. This means that most of the cost using this is not by the notifications, but by the polls (again: unless an ridiculous amount of notifications are sent). A notification is not very big!
> > 5. It's easier to just send it first. If not, you'd have to keep a record
> > off all receivers, and design an error handler that tries to resend the
> > message with a register first if it fails on the first try (error handler
> > since you cannot expect the receiver to tell you it isn't registered when
> > you send...)
> I don't follow this this.
> When you send the request you only see one receiver and it WILL tell you
> if the notification isn't registered. The only time you would have
> multiple receivers would be if your app is forwarding to multiple servers
> (i.e. distributing the notification) - in which case how you handle
> different responses from the different servers is the app's problem.
True. Growl & GNTP is in its current state a one to one solution. One server sends to one client at a time. But each client can have forwarders that pass the messages from the server on to any number of sub-clients. This thread is about that distinct case.. Forwarders. If you want a system where the register message is only sent once, you have to write a forwarder that keeps a database over which clients have received the register-message, and add functionality to the forwarder to generate a register message if it encounters a client that do not match its list, or if a message is not properly received. And again we encounter the problem that the sender is not notified of a failed send due to a lack of registered app...
> > And.. if you build your forwarder / app to use the growl-sending
> > mechanism
> > as a class, you'd have to register a new class instance for each send
> > anyway, so you could with just one line of code extra send a register to
> > the receiving end as well..
> If it is a forwarder (i.e. router or bridge) it should forward only the
> registrations and notifications it receives, and pass back the response it
> receives as it response.
This discussion is about forwarders..
> If it is an app (i.e. a client) it should register all its notifications
> at some point prior to the first notifications. Deciding if this is at
> installation, or when the app starts up, or immediately before the first
> notification, is a design issue that depends on the nature of the
> application and its environment.
True, but the app also needs to be told what info it will receive, and what to do with it. This is sent in the register message, and only there. GfW do not send a message to any server that "my user just deleted this app from from my current app-list".
> > On 30 Oct 2011, at 00:59, IanMM <i...@melsom.be> wrote:
> > Thanks Ian - this makes good sense. Maybe for GNTP/1.1 you could
> > coalesce the NOTIFY and REGISTER directives into a single packet?
> You can't do that as they serve different purposes.
> The register informs the server what notifications the app can send, and
> thus allows a user to customise how the server responds to those messages.
> Without this the server would not know that it could receive a
> notification until it actually got one, which in turn would mean the user
> couldn't configure how it was handled until it was first received.
No.. The server informs the client of this. The server sends the register and notification messages. And since the server will never know what apps a client has, it cant know that the client will know what to do, thus the need to send the register for each message.
> An alternative is to reduce the MUST register requirement to SHOULD
> register - and leave it as a problem for the server as to how to customise
> unregistered types and apps. I would probably reduce it to a SHOULD
> register but also add text saying that the server MAY reject notifications
> that aren't registered.
> > On 30 Oct 2011, at 10:28, IanMM <i...@melsom.be> wrote:
> > Off the top of my head:
> > • Support for digitally signing GNTP packets without the need for
> > encryption;
> Probably simple to add - all you need is support for the END marker - even
> if you don't support connection reuse. Then add the signature as optional
> data on the tail of the END.
> > • Ability to unregister an app by specifying zero notification classes
> > (or a specific UNREGISTER) directive as Snarl supports already;
> I suspect at the moment if GfW gets a registration with 0 entries it will
> effectively unregister. The only use case I can think of is in the
> uninstall - you can't do it at exit as other apps may be running and you
> don't want to delete the related configuration except at uninstall.
Nope. When GfW receives a registration with 0 entries it defaults to a default notification type. Apps do not run continuously in GfW, they are called when GfW receives a notification. This means that you can remove apps in the GfW software simply by right-clicking and selecting "remove application".
What apps are running at the server side that sends messages to GfW is of no matter to GfW. IT simply recreates the app when it receives a new register.
> One issue is that a registration from an app removes the notification
> types that aren't in the new registration. This can cause issues when two
> different versions of the same app are running as each one's registration
> removes any
On Sun, 30 Oct 2011 22:50:48 -0000, IanMM <i...@melsom.be> wrote:
> On Sunday, 30 October 2011 17:23:35 UTC+1, sagji wrote:
>> On Sun, 30 Oct 2011 00:59:35 +0100, IanMM <i...@melsom.be> wrote:
>> > But also..
>> > It is good practice to always send the registration first for the >> > following >> > reasons:
>> > 1. The sender do not know for certain that the receiver has the >> > applications registered in GfW, register makes sure that it is.
>> If you cannot trust the server to keep the previous registration then >> you >> can't trust it to keep the previous registration even if it is sent >> immediately before the notification.
> The _server_ do not keep any registrations, only the recipient keep them. > The server only sends... And yes.. there is a miniscule chance that the > recipient may remove the registered app in the very short period between > the register and the notification. This however would be due to a > software > problem on the recipients side, or a user action/error.. So no.. you > cannot implicitly trust that the recipient has the app registered at all > times.
The server IS the recipient, the client IS the sender. GfW is a GNTP server. If you use say the Winamp plugin then winamp is a client. There are other reasons why the server doesn't have the registration - but there is little point in half solving a rare problem especially if the cost of the solution is high.
>> > 2. You may have changed number or types of notifications, or icons, in >> > the >> > receiving app, the only way to update this is by a new registration.
>> This is the app's problem - and spamming registrations doesn't solve it. >> This is most noticeable if you have two different versions of the app >> running that produce different notifications at the same time. >> Part of the problem is that G4W takes a registration as de-registering >> any
>> type not in the new registration - so the registration from the old >> version removes the new types.
> How do you suggest the app on the recieving end should predict how many > different types of notifications it should have? or what icons to use? It > falls back to default when nothing is given from the server. The number > of > different types of notifications, and what icons to use is defined by the > server, and the apps only way to get updates on this is if the server > tells > it. This is done by registering.
>> > 3. The receiver may have had the app registered but removed it for any >> > number of reasons (re-installs, removal of app for debugging >> reasons,and
>> > so >> > on). If you assume that it is still registered, you'll encounter an >> > error.
>> A registration is needed at some point but not at the notification - >> except in response to a not registered response.
> The current version of Growl an GNTP do not, as far as I know, support an > error message that returns a "not registered" error. It is simply > discarder > at the recipients side. Much like the tcp-protocol that discards unknown > frames..
Read the spec - 401 app not registered, and 402 notification type not registered. I have seen GfW produce a 401.
>> > 4. It has become a defacto best practise standard, take a look at any >> of >> > the other libraries and classes out there that handles your growl >> > communications, they all send register first, then the growl itself.
>> It is bad practice - that "everybody" does it doesn't make it good. It >> reduces the chance of a not-registered error but it doesn't eliminate >> it. >> The closest you can get to solving the problem is to resend the >> registration and the notification in response to a not registered error >> - >> all on the same socket (which G4W doesn't support). Here you can be >> certain the registration is sent to the same instance of the server but >> you can't be absolutely certain that something else hasn't removed the >> registration in the very small amount of time between the two resends. >> It can also significantly increase the volume of network traffic - and >> some people pay based on data volume, or have capped data volumes (such >> as
>> people forwarding to a mobile phone - which can be £1 per MB or more).
>> In percentages, yes (it doubles it from one packet to two), in actual > measurements? Then you'd have to have an ridiculous amount of messages > being sent. But if you look at growl usage, most apps and uses are > localhost (on same machine) or on the Local Area Network (between a > server > sending a tasknotif and a PC). Pulling in mobiles is kinda unfair, since > those forwardes that does this does it by setting up a percistent > connection to a server to poll if there has been sent a message or not. > This means that most of the cost using this is not by the notifications, > but by the polls (again: unless an ridiculous amount of notifications are > sent). A notification is not very big!
Until the app decides to use a 600x600 32bpp bitmap as the icon - that a 1.4 MB file, and Yes I have seem a client do this, and use context specific icons. Now consider a registration message with 5 such bitmaps and tell me that sending the registration every time is a good idea.
>> > 5. It's easier to just send it first. If not, you'd have to keep a >> record >> > off all receivers, and design an error handler that tries to resend >> the >> > message with a register first if it fails on the first try (error >> handler >> > since you cannot expect the receiver to tell you it isn't registered >> when >> > you send...)
>> I don't follow this this. >> When you send the request you only see one receiver and it WILL tell you >> if the notification isn't registered. The only time you would have >> multiple receivers would be if your app is forwarding to multiple >> servers >> (i.e. distributing the notification) - in which case how you handle >> different responses from the different servers is the app's problem.
> True. Growl & GNTP is in its current state a one to one solution. One > server sends to one client at a time. But each client can have forwarders > that pass the messages from the server on to any number of sub-clients. > This thread is about that distinct case.. Forwarders. If you want a > system > where the register message is only sent once, you have to write a > forwarder > that keeps a database over which clients have received the > register-message, and add functionality to the forwarder to generate a > register message if it encounters a client that do not match its list, or > if a message is not properly received. And again we encounter the problem > that the sender is not notified of a failed send due to a lack of > registered app...
No you don't - what ever app generates the notification has to generate a register before hand. The forwarder has to cope with how that app works - thus is needs to pass on the register when ever it gets one, just as it passes on the notifications when it gets them. It has no need to "manage" the registrations - it may cache the registrations and resend them in response to a server replying with a not registered error code (401 or 402) In fact "managing" the registrations introduces the risk of causing problems.
>> > And.. if you build your forwarder / app to use the growl-sending >> > mechanism >> > as a class, you'd have to register a new class instance for each send >> > anyway, so you could with just one line of code extra send a register >> to >> > the receiving end as well..
>> If it is a forwarder (i.e. router or bridge) it should forward only the >> registrations and notifications it receives, and pass back the response >> it
>> receives as it response.
> This discussion is about forwarders..
>> If it is an app (i.e. a client) it should register all its notifications >> at some point prior to the first notifications. Deciding if this is at >> installation, or when the app starts up, or immediately before the first >> notification, is a design issue that depends on the nature of the >> application and its environment.
> True, but the app also needs to be told what info it will receive, and > what > to do with it. This is sent in the register message, and only there. GfW > do > not send a message to any server that "my user just deleted this app from > from my current app-list".
>> > On 30 Oct 2011, at 10:28, IanMM <i...@melsom.be> wrote:
>> > Off the top of my head:
>> > • Ability to unregister an app by specifying zero notification classes >> > (or a specific UNREGISTER) directive as Snarl supports already;
>> I suspect at the moment if GfW gets a registration with 0 entries it >> will >> effectively unregister. The only use case I can think of is in the >> uninstall - you can't do it at exit as other apps may be running and you >> don't want to delete the related configuration except at uninstall.
> Nope. When GfW receives a registration with 0 entries it defaults to a > default notification type.
Which is pointless - without any included notification types it can never be used. The spec should probably be changed so that registering 0 type is either prohibited or acts as an unregister.
> Apps do not run continuously in GfW, they are called when GfW receives a > notification. This means that you can remove apps in the GfW software > simply by right-clicking and selecting "remove application".
Apps don't run in GfW at all apps the the clients that send notifications to servers such as GfW. You can remove the registration record be deleting it in the apps pane of GfW other servers may work differently.
> lots of good discussion here, and i am going to chew on all of it a > bit, but i wanted to note a few things before i forgot:
> 2. The GNTP spec is not clear on it, but a REGISTER request is > *supposed* to replace any existing notification type registrations. > During the initial discussion on the spec, that was the consensus on > what made the most sense. If an app wants to register just a single > new type, they are expected to know what other types they have already > registered for. In the case of two versions of the same app wanting to > register two different sets of notification types, the onus is on the > app to handle its versioning issues, just like it would have to do > with any other app-specific settings or data.
The problem here is that the old version has no knowledge of the message type that will be introduced in a later version so can't possibly register it. Further more with the forwarding of the notifications to other systems you can have two distinct systems with different versions of the app. Yes the new version can send the old notification type - but that leaves it lying around unused and the user can see it in GfW but can't get the app to produce it. After many revisions there may be more old types lying around that active types, and when the user knows which ones are obsolete they have no way of removing them - because the new version is registering them in case there is also an older version on the network.
If the registration was cumulative instead of definitive this wouldn't be a problem - and when the user wants to get rid of the obsolete types that can delete the app's entry and get the app to register again, of GfW could be extended to permit the deletion of individual notification types.
> 3. An UNREGISTER command was deemed unnecessary since a REGISTER > completely replaces all existing registrations (removing the need to > individually unregister notification types) and so the only use would > be for when an app was uninstalled. I can see the case for it there > (just to be a good citizen and remove any trace of the app), but I > think it was decided that if the app was later re-installed, it would > be better to have retained the user's configuration settings for that > app. (otherwise, an app could just unregister and reregister itself > and wipe out the user's preferences).
The only real use is as good housekeeping in an uninstall - which should be optional for the cases when you are reinstalling or upgrading.
