[Top] [All Lists]

the notify issues

2007-01-27 14:18:46


Issue #3: :message vs :subject

I am for
4). notify should have both :message and :subject

Issue #6
"send notification over XMPP, if can be delivered immediately. Otherwise send it over SMS"
I am in favour of:

  1). Add a test to check if a notification method (specified
  as an URI) can deliver the notification immediately.

  1)  Add a test to check if a notification method (specified
  as an URI) HAS delieverED the notification immediately.

Expanations: for sending an SMS, or mail it cannot be said if the message can be delivered immediately, as it depends on many things, and even if a notification can be delivered during the test, this does not mean that it is delivered delivered immediately at a later point, when the notification is send. On the other side, if an SMS of mail is send, an acknowledgement can be requested, that the notification is read/delivered. Naturally, this will mean that the interpreter has to stop for certain time, like 10s, and wait for the acknowledgement.

  2). Keep the existing syntax. A new "stackable" notification method
  can be specified that will perform the desired functionality.

I do not get what means "stackable notification".

Issue #4, expire:
Let's add to
Section 3 Notify Action

   Usage:  notify ":method" string
           [":from" string]
           [":importance" <"1" / "2" / "3">]
           [":options" string-list]
           [":message" string]
*          [":expire" number]

* Section 3.7 Notify tag ":expire"
* If there are errors sending the notification, the parameter of the :expire tag sets for how long in seconds shall it be retried to deliver the notification. If the notification cannot be delivered within the time, it can be discarded. Missing ":expire" leaves up to the implementation to set up some reasonable defaults.
*  A value of 0 (zero) means that delivering the message shall not be retried.

And add an example to the current 3.7

-- Does somebody know a standard, or part of it, to specify time period, but not date? In this way the seconds can be replaced with something easier to write.

# Issue #8, having both content in both :method and :message --
I like:
3). the notify parameters override the corresponding URI parameters
4). specify both the notify and the URI parameters is an error...
... if they lead to generation of different notification.

(it is not an error, if the :message and ?message define the same )

But 3 is more fault-tolerant.

And final suggestion:
   Notifications SHOULD includes means to identify/track its origin, in order
***Notifications SHOULD include  means to          track its origin, in order
   to allow a recipient to stop notifications or find out how to contact the
   sender. This requirement is to help tracking a misconfigured or abusive
   origin of notifications.


<Prev in Thread] Current Thread [Next in Thread>