On Fri, 13 Jun 2008, Luigi Paioro wrote:
> Dear Mark and all,
>
> I'm a bit confused concerning the meaning of samp.app.status and
> samp.app.status.progress MTypes and I think this comes from a more general
> misunderstanding on my part.
Luigi,
I don't think you are misunderstanding, I pretty much agree with your description of how this all works. To clarify though, at the level of the protocol, the MTypes are opaque strings, so the progress of a given message and its response through the system is not affected by its structure (whether it's samp.app.status.progress or samp.app.msg.status.progress). The only exception to this rule of MType opaqueness at the protocol level is MType wildcarding if you want to subscribe to a subtree of MTypes at once.
However, the hierarchical structure of the MType vocabulary clearly does serve a purpose for humans, which is to give a clue about which MTypes mean what. In the context of that fact:
> Then I would rather have (two possibilities):
>
> MType:
> samp.app.msg.status.progress or samp.app.call.status.progress
> Parameters:
> msgid (or callid): message ID (or callid) of a previously sent message
> (or of a previously operation called) (REQUIRED)
> txt: textual indication of progress (REQUIRED)
> percent: numerical percentage indication of progress (OPTIONAL)
> timeLeft: estimated time to completion in seconds (OPTIONAL)
> Return values:
> none
> Description:
> Reports progress on a previously sent message (or operation called).
I agree with the spirit of this proposal - as you say, the progress is progress of a message/call, and not of the application itself. Using samp.app.status.progress for this would not actually break anything, but it is less clear than what you're suggesting.
Of your alternatives, I would favour samp.app.msg.status.progress, or maybe just samp.msg.progress.
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-13Z12:30:42