MType vocabulary design principles

[Mike Fitzpatrick]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/pipermail/apps-samp/attachments/20080612/82359988/attachment-0001.html>