On Fri, Feb 15, 2008 at 6:32 AM, Dan Lester <[EMAIL PROTECTED]> wrote:
> > Just a thought: rpc should cater for the 'nocache' attribute - either in > another input field or with query /rpc?nocache=1. Yes, this will be added. We should probably open JIRA issues for these things. Right now it can be resolved by making it so that instead of passing a dummy ProcessingOptions down to GadgetServer, it passes an HttpProcessingOptions, which will extract nocache params (amongst other things). Eventually, I'd like to refactor the JsonRpc stuff to a generic Rpc interface so that we can support any wire format (JSON, XML, SOAP, whatever). This is especially important to large organizations using shindig that already have custom rpc infrastructure. > > 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/gadgets/rpc%27> > <http://localhost:8080/gadg > ets/rpc%27 <http://localhost:8080/gadgets/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 > > > > > > -- ~Kevin If you received this email by mistake, please delete it, cancel your mail account, destroy your hard drive, silence any witnesses, and burn down the building that you're in.
