m.b.taylor at bristol.ac.uk
Mon Jun 9 04:09:21 PDT 2008
On Tue, 3 Jun 2008, Mike Fitzpatrick wrote:
> So, the list of admin mtypes I have now is:
I agree with all these.
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 Taylor Astronomical Programmer Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
More information about the apps-samp