Re: [Plastic-devs] Future API changes

[Mark T. <m.b...@br...>]

John, I'm exploding this to the mailing list, where I probably should
have started off the conversation, hope you don't object.  
I think there's enough context here for other readers to pick up 
what we're talking about.

On Tue, 18 Jul 2006, John Taylor wrote:

> 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).

  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?)

> We might want to keep the application's understood messages out of this 
> struct though, to allow them to be changed post-registration as per your 
> earlier email.

yes, good point.


> > 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.

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?

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/