Hello,
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
Or
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.
Greetings,
Dilian