MType vocabulary design principles

[John Taylor]

It might be useful to think about when why we want separate MTypes at all.
With SAMP's  flexible named parameter passing we could in principle just
have one uber MType
analyze.this()
that just took different named parameters to indicate whether it's talking
about loading up a votable, processing an image or warning of an application
unregistering.  The reasons we define different MTypes for different jobs
are
* So that a sender can dispatch a message to an app and have some reasonable
expectation it will be acted on (particularly important if that sender is a
human) since the sender has declared an interest in it
* So that recipients don't have to be interrupted for messages they have no
intention or capability of acting on

In the example you give below of progress messages I'd say neither of these
apply.  I've declared I'm interested in progress messages.  Send me progress
messages.  I want to be interrupted by progress messages.  OK, if you send
me the progress in units of frogs I can't do anything useful with it, but
I'm sure you'll also supply the "fallback" parameter of a text string too,
so I'll use that.
*Please* use one MType for this.

John


On Wed, Jun 11, 2008 at 5:11 AM, Mark Taylor <m.b.taylor at bristol.ac.uk>
wrote:

> All,
>
> the issue of what MType(s) to use for progress messages brings up a
> question with much wider applicability in designing the MType vocabulary.  I
> think that getting the design principles of that right will be important to
> maximise interoperability in practice. In my opinion if the MType vocabulary
> becomes too large or fine-grained it will be hard to recover the kind of
> interoperability for PLASTIC-like applications which PLASTIC has achieved.
>  Because of the importance of this I would urge application authors to
> consider the points raised here (and perhaps subsequently on this thread)
> and to contribute their views to the debate.
>
> On Tue, 10 Jun 2008, Mike Fitzpatrick wrote:
>
>  On Mon, Jun 9, 2008 at 4:09 AM, Mark Taylor <m.b.taylor at bristol.ac.uk>
>> wrote:
>>
>>   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.
>>>
>>
>>   Percent and timeLeft are just two examples, one might also consider
>> 'bytesDownloaded', 'filesRemaining', 'messagesHandled', etc.  Some of
>> these are likely to be application-specifc, the above hierarchy provides
>> a framework to hang these new mtypes on without later polluting the
>> list of optional args, and simply reserves the mtype for the types of
>> progress most apps would likely implement.  As with any mtype, at
>> least two apps would have to understand app.status.progress.frogsEaten
>> for it to be meaningful, the rest would ignore it.  I don't see where
>> interoperability is an issue.
>>
>
> Having multiple different MTypes which do similar things leads to a
> tradeoff between interoperability and burden on the participants.
> The basic problem is that if there is a (wide) choice of MTypes which might
> apply to the message you want to send, then there is a (serious) risk that
> the sender and the recipient will fail to agree on which one to use.  To
> cope robustly with this, clients at both ends have
> to use all the variants, which is more work.
>
> This is an example of a general question which is going to come up in
> relation to many other MType definitions, so it's worth some
> discussion.  It's the question of whether it is better to "pollute"
> the namespace of defined MTypes or the per-MType namespaces of (maybe
> optional) MType parameters.  More neutrally: for a related
> set of functionality, is it better to handle semantic flexibility
> by defining one MType with flexible optional parameters, or multiple
> MTypes each with relatively constrained parameters.
>
> Looking at these progress messages specifically, consider the situation
> from the sender's point of view.  If there is a set of related
> app.status.progress.* MTypes as you suggest, the sender could just do:
>
>   notify( clientId, app.status.progress.percent( percent="50" ) );
>
> however, if the recipient is only subscribed to
> app.status.progress.timeLeft then there is no information exchanged
> and no interoperation.  In general there is the possibility, and indeed
> likelihood, that the MType the sender decides to send is not the same as the
> MType the potential receiver will decide to subscribe to.
>
> So, to be safe, the sender really ought to do this:
>
>   notify( clientId, app.status.progress( txt="50% done" ) );
>   notify( clientId, app.status.progress.percent( percent="50") );
>   notify( clientId, app.status.progress.timeLeft( timeLeft="96" ) );
>
> or, better (because it reduces unnecessary traffic), this:
>
>   if ( isSubscribed( clientId, app.status.progress ) )
>       notify( clientId, app.status.progress( txt="50% done" ) );
>   if ( isSubscribed( clientId, app.status.progress.percent ) )
>       notify( clientId, app.status.progress.percent( percent="50" ) );
>   if ( isSubscribed( clientId, app.status.progress.timeLeft ) )
>       notify( clientId, app.status.progress.timeLeft( timeLeft="96" ) );
>
> There are three problems with this:
>
>   1. It's more coding effort for the sender
>   2. The number of messages transmitted through the system may be
>      higher than it needs to be
>   3. It will still fail to transmit progress information if the
>      recipient is only subscribed to, e.g.,
>      app.status.progress.frogsEaten
>
> In the alternative way of doing it, there is one MType named
> app.status.progress with a required parameter txt and documented
> optional parameters percent and timeLeft.  Then I can write just
>
>   notify( clientId, app.status.progress( txt="50% done",
>                                          percent="50",
>                                          timeLeft="96" ) );
>
> or, better,
>
>   if ( isSubscribed( clientId, app.status.progress ) )
>      notify( clientId, app.status.progress( txt="50% done",
>                                             percent="50",
>                                             timeLeft="96" ) );
>
> I can add on frogsEaten="23" and byteDownloaded="9999" parameters if I
> want.
>
> This is easier to code, it means there is only one message sent per
> progress event thus reducing load on the messaging infrastructure and
> recipient, and it guarantees that if both sides are interested in
> progress information at all they will be able to communicate about it to
> some extent, even if it's only a text string (which in practice
> can always be generated by a sender, and can nearly always be made
> some use of by the recipient).
>
>
> This specific case aside: when deciding how broadly defined specific MTypes
> should be (what goes in parameters and what warrants a
> new MType) it will in general be necessary to look at the details
> on a case by case basis.  But I would say that in most cases, because of
> the kinds of considerations I've outlined above,
> it is better to keep to a small number of MTypes, and to handle semantic
> flexibility with (perhaps optional) parameters.  I suggest the following
> rules of thumb:
>
>   1. If an application wants to perform some specific kind of
>      interoperation with another, it should be clear which MType
>      to use for that, rather than there being a selection of
>      similar ones available which differ in detail.
>
>   2. It's OK to define or use as many optional parameters as are
>      useful for an MType as long as a recipient which ignores
>      all the optional parameters can still stand a good chance
>      of processing the message in a sensible fashion.
>
> These arguments are most important when considering a PLASTIC-like
> scenario in which applications are communicating with other applications
> which they may never have met before in a relatively uncontrolled
> environment.  However I don't believe that doing it the
> way I am advocating will be disadvantageous even in more controlled
> environments.
>
> Mark
>
> --
> 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/<http://www.star.bris.ac.uk/%7Embt/>
>



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