I agree with John on this.
In the interest of generality I'd prefer a simple app.status mtype that asks
simply
to process a status message (Mark has a point about 'app.event.status', but
this
isn't really an event per se and we can define 'app.status' in the form of a
request (e.g. 'please process this status') if needed). If we have just the
one mtype
defined to be a status string then senders can write what they like, and
receivers
who subscribe only need to support displaying it in some way. If a sender
wants to
put it in terms of time/percent/frogs that's fine, but the receiver only
needs to
put up a string in a dialog and not care about the format. Leave the
"*.percent"
to apps that want to display a progress bar as a GUI element to be worked
out
by themselves with an app-specific mtype.
Percent and timeLeft I think cover most cases, but if it means opening
mtypes to
arbitrary optional args I'd just as soon drop it for a common app.status
that says
you'll get a string to display/log/whatever.
-Mike Received on 2008-06-12Z11:08:12