Hi Guys,
The 'hub.event.stopping' was derived from the PLASTIC message of a similar name but I really think it could be just 'hub.event.shutdown' to be more explicit. This would avoid confusion with the app.{starting,stopping} but I also agree that at least those two are application specific things that belong in the second doc.
That said, I'd still like to have an 'app' class of messages since not every administrative message will be coming from the hub. My sense is that app.echo and app.isAlive really mean the same thing and could be just 'app.ping' or somesuch (after all, if an app isn't alive it would never respond, but then neither would any other message).
My presentation slides left out a 'status' class of mtypes in part because the list was mixed with the idea that a response would be a message and have an mtype. However, there were also mtypes that could be used to e.g. post a progress message giving completion percentage, time remaining, or just a free-form string to indicate progress or status. I could see where a status string might be used in some sort of logging pattern. To come full circle, I don't see any reason why an app can't signal it's about to shutdown either (e.g. in some sort of onexit procedure before a crash).
So, the list of admin mtypes I have now is:
hub.event.shutdown hub.event.register hub.event.unregister hub.event.mtype hub.event.metadata
app.ping
app.event.shutdown
app.status str status string 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)
The progress mtypes need the msg-id to indicate progress on which originating request, I'm open to suggestions that app.status could just be a separate 'status' class. Are there any other application events or actions we want to reserve for use in the spec?
Lastly, did we settle the question of whether users can extend the hub/app toplevel classes or are we saying e.g. that any app.* message is reserved for the spec? Can anyone imagine a use-case where they implement a hub and want to define their own hub.* mtype for some particular reason?
Cheers,
-Mike
Received on 2008-06-04Z07:53:58