Administrative MTypes

[John Taylor]

On Wed, Jun 4, 2008 at 1:53 AM, Mike Fitzpatrick <fitz at noao.edu> wrote:

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


I care little about the names used for the messages, but just for historical
background we used the present continuous tense since this gets fired off
when the hub is in the process of shutting down.



>
>
>        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).


I'd agree with that.  I put the echo message in just for test purposes as
something I could send and not cause any side effects.  ping does the same
job.

John


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



-- 
Google Pittsburgh is hiring!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/pipermail/apps-samp/attachments/20080604/72a89edf/attachment-0001.html>