MType vocabulary design principles

[Mark Taylor]

On Thu, 12 Jun 2008, Mike Fitzpatrick wrote:

> 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,

I'm not sure if you're talking about the app.status or 
app.status.progress MTypes here; I think John was discussing only 
progress messages (as I was in the message he replied to) but you're 
talking about app.status above.  If you're saying that app.status 
and app.status.progress should be collapsed into a single message: 
I don't agree, because the app.progress MType(s) is talking about 
progress of a particular previously sent message, while the app.status 
one presumably concerns the status of the sending application as a whole.
These seem to require distinctively different behaviours - for instance
a client might be sending progress messages about two different previous
requests at the same time, and you wouldn't want them to get mixed up.

Unless you say different, since you're agreeing with John and he was
agreeing with me ... I'll assume that you're happy with something like
the following:

    MType:
       samp.app.status
    Parameters:
       txt: textual indication of status (REQUIRED)
    Return values:
       none
    Description:
       General purpose message to indicate application status.

    MType:
       samp.app.status.progress
    Parameters:
       msgid: message ID of a previously sent message (REQUIRED)
       txt: textual indication of progress (REQUIRED)
       percent: numerical percentage indication of progress (OPTIONAL)
       timeLeft: estimated time to completion in seconds (OPTIONAL)
    Return values:
       none
    Description:
       Reports progress on a previously sent message.

(though looking at this again, I'm more persuaded that these ought to
have a ".event." in their names, since if we wanted an MType to mean
"what is your status?" what would that be called?  However I don't insist
on that since as long as the definitions are right I'm not too bothered
about the names)

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/