Re: [Plastic-devs] Future API changes

[John T. <jon...@gm...>]

>> Mark Taylor wrote:
>>     
>>> One possibility is to replace hub methods getName(), getRegisteredIds(),
>>> getUnderstoodMessages() and getMessageRegisteredHubIdsPleaseIfYouDontMind()
>>> with a single getRegisteredApplications() which returns an 
>>> <array>-of-<struct>s/List-of-Maps giving all the information that
>>> the hub knows from registration time about every registered application
>>> (name and supported message IDs).  I'm not saying it's a good idea mind.
>>>
>>>       
>> Actually I quite like this.  Instead of registering with your name, you 
>> register with a struct containing your name, ivorn, iconurl, description 
>> + whatever else we decide to put in there in the future.  We'll define a 
>> few well-known keys to get started, but people can expand the struct as 
>> they see fit.  And you have a single method to return the lot, as you 
>> just described. 
>>     
>
> I hadn't thought of doing it for registration as well, but that probably
> makes sense if we're going to do that.  Downsides:
>
>   1.  Different from current practice (but looks like we may be heading
>       for a backwardly-incompatible change to the protocol sometime
>       soon so may as well make the most of it).
>   
I don't know about soon, but it would certainly be good to think of as 
many such changes as we can and get them done in one go.
>   2.  One call fits all may mean you're transmitting more data than you
>       need to - however we're probably not talking about very large
>       amounts so this is probably not important.
>
>   3.  Means you can neither register not obtain any application metadata
>       without the ability to process structs.  This is probably going to 
>       scupper any attempt to use HTTP-GET for PLASTIC access.  There
>       may be other platforms too that don't lend themselves to an
>       XML-RPC implementation which can decode structs (i.e. don't
>       have langauge features resembling associative arrays/hashes) - 
>       can anyone think of examples of this which might be important (IDL?)
>   
This could be an issue, though even with our current spec, http-get is 
very limited and is pretty much limited to "load-this-file" type 
messages so perhaps it's not much of a loss.
We should check up on the progress (if any) of the IDL xml-rpc library.  
The other environments I'd like to have plastic-access from are "R" and 
web pages.  I think that having a very small applet to do the comms is 
probably the way to go for web access.  As for R, I currently have an 
http-get solution, but it's not particularly good.

[]
>
>   
>>> Now (v0.5) that you can't register to receive all messages by sending 
>>> an empty supportedMessages array at registration time, we're
>>> missing a way for monitor-type applications to see everything that's
>>> going on in the hub (good for debugging).  This could be addressed
>>> by a new message
>>>
>>>    id:
>>>        ivo://votech.org/hub/event/requestSent
>>>    args:
>>>        String senderId
>>>        String messageId
>>>        List recipientIds
>>>        String requestId
>>>    return type:
>>>        void
>>>
>>> which the hub sends to interested parties whenenever it makes a 
>>> request to listeners (er, with the possible exception of requestSent or 
>>> responseRecieved requests...).  The requestId argument is just a 
>>> string unique to this request.
>>>
>>> We also introduce a second message
>>>
>>>    id:
>>>        ivo://votech.org/hub/event/responseReceived
>>>    args:
>>>        String requestId
>>>        String recipientId
>>>        Object response
>>>    return type:
>>>        void
>>>
>>> Here the requestId is used to match the response up with the
>>> earlier-notified request, for those that care.
>>>   
>>>       
>> I like it.  Let's put the senderId in there as well, just so that the 
>> client doesn't _have_ to match up the two messages to find out who the 
>> response is going to.
>>
>>     
>>> Monitor-type applications can now see all the requests that go out from
>>> and all the responses that come back to the hub, which is good.
>>>
>>> A bonus is that this pair of messages can also be used by applications
>>> which want to use callbacks to get responses from the hub; either
>>> because they're not multithreaded or because response times are
>>> potentially slow.  Instead of calling request() synchronously,
>>> they call requestAsynch() and make sure they're registered to 
>>> receive requestReceived messages (ignoring ones they didn't send
>>> in the first place if necessary).  None of this requires any additional
>>> hub methods.
>>>   
>>>       
>> This is promising, but I have a couple of comments:
>> 1) We could reduce the burden on the client of sifting through all the 
>> responses by having a similar
>>
>> ivo://votech.org/hub/event/myResponseReceived
>>
>> message that only gets sent to the sender of the original message.
>>     
>
> OK.
>
>   
>> 2) It could be a little tricky matching up responses to messages.  If 
>> you're monitoring the requestReceived message you can tie them together 
>> using your proposed requestId, but it's not obvious to me how you tie 
>> together (with certainty) your original call the the hub with the 
>> response message.  Maybe it doesn't matter.  
>>     
>
> Hadn't thought of that.  However, I can think of a good solution:
> get the hub requestAsynch() methods to return the responseId for the
> request rather than void.
>   
Yes, that sounds workable.
> Thinking about it, with this in place you can achieve anything using
> the asynchronous hub request methods that you could before using 
> the synchronous ones (though with more client-side work).  
> The possibility therefore arises of ditching the synchronous 
> hub request methods.  Is that a bit too radical?
>   
We'd then lose the ability to get data back to non-callable environments 
such as command-line python.

John