[Top] [All Lists]

Re: values of notify ":priority" tag

2005-12-06 12:50:55

Assuming the majority likes :priority, I agree to the above and suggest
to allow arbitrary values, like :from does, because each method might
use different data formats as sender.  For SMTP, it is certainly a
mail address, for SMS a phone number or an alphanumeric sender tag.
Saying :priority must be defined as in RFCs relevant to e-mail makes
sense for SMTP, but not neccessarily for SMS.

Hm, but that rather misses the point of :priority.  It's not meant to specify
some channel-specific priority setting, but to define the priority of the
notification itself.  It's saying, "It is very important (or normal importance
or low importance) that this notification be sent to the user."  That importance
might be used in some way to determine how (or whether) to perform the

Suppose, for instance, we have a notification mechanism that is able to
determine "how busy" I am.  That mechanism might decide to match the
notification's priority my busy status, informing me only of high-
priority notifications if I am "very busy", of all notifications if I am
"not busy at all", and so on.

Alternatively, some notification mechanism might know, per user, of a set
of different ways that different users could be notified, and it might use
the importance of the notification to decide which to use.  (This use-case
certainly argues for more than three levels.  On the other hand, I can't
imagine how more than a few choices could reasonably be coded into a script.)

It certainly COULD be used to set the value of an X-Priority header for
an email-based notification, if the mechanism decided to define that.  But
that's not basically what it's there for.

Which is why I've suggested, in my last editing pass (which Alexey now has,
and y'all haven't seen yet), to suggest changing it to ":importance",
rather than ":priority".

Of course, we still might decide that it's a bad idea, and take it out.  But
let's just be clear about why it's there in the first place, before we do that.


Barry Leiba, Pervasive Computing Technology