Just a thought: rpc should cater for the 'nocache' attribute - either in another input field or with query /rpc?nocache=1.
Otherwise, I get the cached version for the info, then the ifr might return a newer version. Of course, under normal usage without nocache=1 there's no guarantee the cache won't expire between these stages. In fact, even with nocache=1, the XML could be changed between calls. Looking at the code, I wondered if query parameters should be passed to gadget server when invoked by the rpc servlet, but in tests it certainly doesn't work. Thanks, Dan -----Original Message----- From: Kevin Brown [mailto:[EMAIL PROTECTED] Sent: 11 February 2008 22:09 To: [email protected] Subject: Re: Getting Gadget Info without rendering gadget That's exactly the intended use for RpcServlet. Great example! On Feb 11, 2008 2:04 PM, Dan Lester <[EMAIL PROTECTED]> wrote: > > OK, I'll keep checking out and trying the Rpc again over the next few > days. I'm playing around with both Java and PHP at the moment (but > both using Java gadget server of course). My initial code to get info > over Rpc just used curl in something like: > > > $gadgets_array = array(); > > foreach ($gadgetUrls as $url) { > $gadgets_array[] = array( 'url' => $url, > 'moduleId' => > count($gadgets_array)+1 ); > } > > $req = array( > 'context' => array( > 'country' => 'US', > 'language' => 'en', > 'view' => 'default' ), > 'gadgets' => $gadgets_array ); > > $rpc = new > RpcSender('http://localhost:8080/gadgets/rpc'<http://localhost:8080/gadg ets/rpc%27> > ); > $info = $rpc->Send($req); > > class RpcSender { > > private $addr; > > function __construct($addr) { > $this->addr = $addr; > } > > public function GetAddr() { > return $this->addr; > } > > public function Send($req) { > // req is an array-object that needs to be JSON-ified > > $json_req = json_encode($req); > > $ch = curl_init(); > curl_setopt($ch, CURLOPT_URL, $this->GetAddr()); > curl_setopt($ch, CURLOPT_POST, 1); > curl_setopt($ch, CURLOPT_POSTFIELDS, $json_req); > curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); > > $res = curl_exec($ch); > > if (curl_errno($ch)) { > $res = null; > // Should handle curl_error($ch); > } else { > $res = json_decode($res, true); > } > > curl_close($ch); > > return $res; > } > } > > > > -----Original Message----- > From: Kevin Brown [mailto:[EMAIL PROTECTED] > Sent: 11 February 2008 19:58 > To: Dan Lester > Cc: [email protected] > Subject: Re: Getting Gadget Info without rendering gadget > > > On Feb 11, 2008 11:23 AM, Dan Lester <[EMAIL PROTECTED]> wrote: > > > Kevin, > > > > The JsonRpc servlet is a great contribution - I've got it working > > from > > > PHP. > > > > However, is there any chance it could return all available details > > from the spec? That would include thumbnail_url, width, height, > > author_email, etc - every attribute on the ModulePrefs tag, I > > suppose. > > > Yes, these will be added. Not all of them are currently supported on > the GadgetSpec interface. I'll be adding these over the next few days > (after submitting the pending headers patch; see SHINDIG-56). I think > we'll ultimately wind up supporting the entire extended spec here, not > just the canonical one. > > > > > > You mention that error handling is "kind of rough". I think any > > client > > > can just cater for the idiosyncrasies for now, but one glaring issue > > is that any one gadget spec not found causes the whole call to break > > (returns 'Incomplete processing'). That rather ruins your hard work > > to > > > allow multiple gadget specs to be fetched at once. > > > I went ahead and fixed this in SHINDIG-56 as well. I didn't realize it > was breaking when anything failed, but rather only when something went > horribly wrong. I'll double check this. > > > > > > > > SHINDIG-25 is marked as closed which is why I'm bringing it up > > rather than just waiting to see if you had anything more in store... > > > I'd like new , individual bugs to be opened for specific issues as > they're encountered, which is why I closed SHINDIG-25. > > I'm glad you appreciate it, though. Thanks for the feedback! > > ~Kevin > >
