ISSUE: Naming of error object encoding

[Alasdair Allan]

Mike Fitzpatrick wrote:
> I'm sorry for casting your thoughts in such a simple manner, I know  
> that's not the case or your intent, but I'm feeling like  
> generalizations  that do no  apparent harm to the spec have been  
> met with resistance simply because  there seems to be no immediate  
> use for it.


The entire beauty of PLASTIC was that it was so simple it could be  
easily added to an existing application, if SAMP is made too  
complicated only the IVOA crowd will add SAMP support, there won't be  
wide spread adoption outside the VO-centric world, and we may as well  
all have stuck with PLASTIC (in fact we would have been better off  
doing that because PLASTIC adoption will be down as well because it's  
no longer seen as supported). If SAMP becomes overly complicated,  
then nobody except the VO will use it. The VO is not the big, wide,  
world.

I'm glad someone is fighting generalisations, generalisations usually  
mean complications. Complications means coding overhead, coding  
overhead means lower adoption.

In this specific case I think you're arguing over something that  
doesn't matter. The functionality the Hub/Client has will not be  
improved in any way by defining the synchronous return messages as  
having mtype. Arguing that synchronous responses to messages aren't  
defined as messages does not increase functionality. In fact I think  
it further nails down the spec in what I think are bad ways, less  
wiggle room beyond the basic framework necessary for the apps to talk  
to each other at all, is bad.

Al.