SAMP draft document introduction

[Alasdair Allan]

>> Should be listed in section 3.10 as an operation the hub must  
>> support, surely? Which is where I was looking...
>
> not unreasonable.  However, as I said:
>
>> This is profile-dependent, since one could imagine other profiles
>> in which, for instance, you can always assume that the messaging
>> subsystem is present.
>
> To elaborate: some of the participants in the debate prior to it
> appearing on this list were concerned that "implementation details"
> should be removed from the abstract API described in sec 3.10
> and described only in relation to the particular choice of wire
> protocol etc that we were using (i.e. the Standard Profile section).

*nod*

Entirely reasonable...

> The particular point of contention raised was including the private- 
> key argument in methods described there.  I thought that the isAlive 
> () method was in a similar class, so moved it out of the abstract  
> API.  But maybe I was being overly picky.  I'm happy to move isAlive 
> () back to where it can be more easily found, the abstract API, if  
> nobody objects to that.  Anyone?

I can see your point, you could have some wire protocols where isAlive 
() is implicit, but I think it should get a mention in 3.10. It's a  
section talking about mandatory things, and some way of finding out  
whether the hub is alive has to be mandatory.

So, maybe you should not list it with the rest of the standard  
profile calls, but mention that a way to find out whether the hub is  
running is mandatory, and that for the API mapping for XML-RPC this  
is implemented using an isAlive() method...?

But basically, I think you're being too picky... ;)

Al.

Al.