Administrative MTypes

[Mike Fitzpatrick]

On Mon, Jun 9, 2008 at 4:09 AM, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:

>>  app.event.shutdown
>
> .......  So I think I would
> argue for withdrawing this from the official list of admin messages
> in the spec.  But I don't insist on this if Mike or others feel strongly.

     I'm not sure I'd say I feel 'strongly' about it, but I do think this is
a valid mtype and keeping it does no harm.  Another use case that
may change your mind:  An app has become unresponsive for whatever
reason and so can't itself unregister or issue a shutdown, so after a
while the hub quits talking to it and issues an app.event.shutdown to
all the other clients on its behalf.


>
>>  app.status                    str             status string
>
> what is the use case for this one?  Is there supposed to be a list
> of known statuses?

No specific use case other than a general way to issue a status
string.  These might be used for debugging or logging, to broadcast
a loading/busy/done message, ......

>
>>  app.status.progress           msgid,str       progress string
>>  app.status.progress.percent   msgid,float     percentage completed
>> (float)
>>  app.status.progress.timeLeft  msgid,int       est. time remaining (sec)
>
> As I've said, I think a progress MType is a good idea.  However, I would
> rather see this as a single MType (app.status.progress) with required
> arguments msgid and progress string, and optional arguments giving
> percentage completed and time remaining.

    Percent and timeLeft are just two examples, one might also consider
'bytesDownloaded', 'filesRemaining', 'messagesHandled', etc.  Some of
these are likely to be application-specifc, the above hierarchy provides
a framework to hang these new mtypes on without later polluting the
list of optional args, and simply reserves the mtype for the types of
progress most apps would likely implement.  As with any mtype, at
least two apps would have to understand app.status.progress.frogsEaten
for it to be meaningful, the rest would ignore it.  I don't see where
interoperability is an issue.


-Mike