Thanks, Dmitri. This is a great idea. Unfortunately though, in this project, I don't have control over what's returned by the server, so I can't add the requestId. But with your suggestion, you still end up needing to match requestIds with handlers on the client right? So do you use a massive switch for that? Thanks again.
LT --- In [email protected], "Dmitri Girski" <[EMAIL PROTECTED]> wrote: > > If I were you, I would simply add the requestId into the server's > response, so client always knows which request-response pair it > handles. This idea lies behind most of the transmissions protocols. > > Cheers, > Dmitri. > > > > --- In [email protected], "lagos_tout" <lagos.tout@> wrote: > > > > Hi, > > > > I'm re-using an instance of HTTPService, changing the request > > arguments to get different responses from the server. But I found > > that if, for instance, I made 3 calls this way with the HTTPService, > > each of the 3 result handlers registered for each call is executed > > every time a result returned. > > > > I solved this by storing a reference to the unique AsyncToken returned > > by each service call and matching it to the AsyncToken contained in > > each ResultEvent's "token" property in order to determine which result > > handler to execute. > > > > I'm not terribly happy with this setup. It seems messy. I'd > > appreciate any suggestions on how I can reuse an HTTPService instance > > without ending up with long switch statements with countless "if > > thisAsyncToken then do thisHandler, else if thatAsyncToken then do > > thatHandler... and so on". > > > > Thanks much. > > > > LT > > >
