Mike,
On Tue, 3 Jun 2008, Mike Fitzpatrick wrote:
> 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
I agree with all these.
> app.event.shutdown
I'm not sure about this. In most cases, other clients can just listen for a hub.event.unregister message concerning the application in question. I agree that there is a difference between an application saying that it's actually going to shut down and saying it is just going to withdraw from SAMP communications, but in most cases as far as other clients are concerned these will amount to the same thing. 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.
> app.status str status string
what is the use case for this one? Is there supposed to be a list of known statuses?
> 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. For one thing, something like a GUI progress bar would probably want to show all of that information (if it's available). For another thing, with multiple similar MTypes it becomes harder work to be reasonably sure that you can interoperate - the sender would effectively need to send all variants and the receiver would need to understand them all. A single progress MType simplifies implementation at both ends.
Mark
-- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2008-06-09Z13:09:21