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 Received on 2008-06-10Z21:14:27