Administrative MTypes

[Mike Fitzpatrick]

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