On Sun, 30 Oct 2011 00:59:35 +0100, IanMM <i...
> But also..
> It is good practice to always send the registration first for the
> 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
> 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
> on). If you assume that it is still registered, you'll encounter an
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
> 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
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
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
> • Register port 23053 with IANA, or switch to a registered port.
The port is currently unassigned - so no need to switch to a different
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
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
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
This would also allow you to
read more »