MType vocabulary design principles
fitz at noao.edu
Thu Jun 12 02:08:10 PDT 2008
I agree with John on this.
In the interest of generality I'd prefer a simple app.status mtype that asks
to process a status message (Mark has a point about 'app.event.status', but
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
defined to be a status string then senders can write what they like, and
who subscribe only need to support displaying it in some way. If a sender
put it in terms of time/percent/frogs that's fine, but the receiver only
put up a string in a dialog and not care about the format. Leave the
to apps that want to display a progress bar as a GUI element to be worked
by themselves with an app-specific mtype.
Percent and timeLeft I think cover most cases, but if it means opening
arbitrary optional args I'd just as soon drop it for a common app.status
you'll get a string to display/log/whatever.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the apps-samp