Re: Proposed new core library: alert.el

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 06 Nov 2015 20:04:49 -0500 "John Wiegley" <jwiegley@gmail.com> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Yes, this is simply a `message' call. I think the only thing missing is
>> metadata and I would draw inspiration from syslog: level, facility, and
>> tags. Then the *handler* should decide what to do with the message based on
>> the metadata.

>> I'm not sure how to provide the metadata, and it should be ignored by the
>> default (current) message handler. Maybe it could be string properties
>> applied to the first parameter? I *need* to know this before writing code.

JW> Ted, I must have missed where this discussion about metadata came up. alert.el
JW> already has a facility for passing and consuming metadata. Would there be a
JW> need to consider another scheme also?

OK, let me explain.  Looking at alert.el.  The severity is good, same as syslog.

There is no facility or tags in alert.el (although I think :type and
:category sort of map to those syslog terms).

Most importantly, alert.el takes a plist, which is not compatible with
`message'. To make it a standard interface, it should just take a string
(with possibly some other parameters for `format'), hence my proposal to
take the plist entries and pass them as string properties to the one
required parameter. From alert.el, the work required would be to provide
a `alert-message-handler' function which takes that string and converts
it to the plist format.

So (message "mystring-with-properties" x y z) where the string has
properties :severity 'foo :facility 'bar would get eventually translated
to an alert call that extracted the properties from
"mystring-with-properties" to yield

    (alert "mystring-with-properties" :severity 'foo :type 'bar)

I think the alternative would be to allow `message' to take a plist,
which I don't think is as good, and would still require translation from
`message' generic properties 

I hope that explains it.

Ted