GNTP forwarding
Phat Bob
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?
Thanks
Rob
Alan Montgomery
>
> 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.
> Thanks
>
> Rob
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Phat Bob
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)?
>
>> Thanks
>>
>> Rob
>>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
> --
> 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-fo...@googlegroups.com.
> To unsubscribe from this group, send email to growl-for-wind...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
>
Alan Montgomery
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.
Phat Bob
On 29 Oct 2011, at 17:51, "Alan Montgomery" <Al...@alanmontgomery.orangehome.co.uk> wrote:
> On Sat, 29 Oct 2011 15:26:31 +0100, Phat Bob <phatb...@gmail.com> wrote:
>
>>
>>
>>
>> On 29 Oct 2011, at 15:10, "Alan Montgomery" <Al...@alanmontgomery.orangehome.co.uk> wrote:
>>
>>> On Sat, 29 Oct 2011 14:33:52 +0100, Phat Bob <phatb...@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.
Thanks - i'll go forward in that vein
IanMM
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..
Phat Bob
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.
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..
--
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.
IanMM
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.
Phat Bob
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.
--
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.
Alan Montgomery
> 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.
This would also allow you to provide support for alternative media. If the
resource was specified as
Notification-Icon: mime-type:"video/mp4"
x-growl-resource://6027F6C0-64AF-11DD-9779-EEDA55D89593
Notification-Icon: mime-type:"image/png"
x-growl-resource://ADFF63C0-614F-1109-7279-EA5853454FFF
Then the server could request only the resource it wanted - the first one
it supports. It could even request the first one, see if it can decode it
and if not send another MISSING_RESOURCE (101) response and get for the
second.
Another issue is that the client doesn't find out anything about the
server until it has finished sending the request. If the server started
its response on connection - that is it sends the "GNTP/1.1 " of the
response - then the client would know what it supports before sending the
request. The only issue might be that an old app seeing any data from the
server may assume the server has received all the data it wants.
Phat Bob
On 30 Oct 2011, at 16:23, "Alan Montgomery" <Al...@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.
We don't need anything that sophisticated.
>
>> 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.
The "space trimming" one was one such example.
>
> 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.
>
That's true until IANA assign it to someone and that someone then gets stroppy because you're now using their port. Safer to have it assigned now IMO - IANA are easy to deal with and it's usually a breeze if you (a) don't want a 0-1023 port and (b) you have your protocol documented.
>> 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.
>
> This would also allow you to provide support for alternative media. If the resource was specified as
> Notification-Icon: mime-type:"video/mp4" x-growl-resource://6027F6C0-64AF-11DD-9779-EEDA55D89593
> Notification-Icon: mime-type:"image/png" x-growl-resource://ADFF63C0-614F-1109-7279-EA5853454FFF
> Then the server could request only the resource it wanted - the first one it supports. It could even request the first one, see if it can decode it and if not send another MISSING_RESOURCE (101) response and get for the second.
All of these would be good to have.
>
> Another issue is that the client doesn't find out anything about the server until it has finished sending the request. If the server started its response on connection - that is it sends the "GNTP/1.1 " of the response - then the client would know what it supports before sending the request. The only issue might be that an old app seeing any data from the server may assume the server has received all the data it wants.
some form of No-op would be useful as this would allow the client to quickly determine the server version from the response header it receives.
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
> --
> You received this message because you are subscribed to the Google Groups "growl for windows" group.
Brian Dunnington
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.
IanMM
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.
> 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.
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.
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.
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 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.)
Alan Montgomery
>
>
> 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.
Read the spec - 401 app not registered, and 402 notification type not
registered. I have seen GfW produce a 401.
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.
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.
Alan Montgomery
<briandu...@gmail.com> wrote:
>
> 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.