Mailing-List: contact shindig-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: shindig-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of etnu@google.com designates
 216.239.45.13 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=received:message-id:date:from:to:subject:in-reply-to:
	mime-version:content-type:references;
	b=YQ/p4p3uz7gWLxyInasHyHcTuWDF+BX0qMWZz+qTq4dPIzENLY3aeRc18EeEpWtJO
	y8fHXr+2A8QAAjaGrWSEA==
Message-ID: <aa285c160802111408h26c6c791r79a01e5a5b57cf4c@mail.gmail.com>
Date: Mon, 11 Feb 2008 14:08:57 -0800
From: "Kevin Brown" <etnu@google.com>
To: shindig-dev@incubator.apache.org
Subject: Re: Getting Gadget Info without rendering gadget
In-Reply-To: <00a701c86cfa$130b2360$2101a8c0@LESTERSATELLITE>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7172_13788011.1202767737757"
References: <aa285c160802111158m75e391bdrace7adf061a4d493@mail.gmail.com>
	 <00a701c86cfa$130b2360$2101a8c0@LESTERSATELLITE>

------=_Part_7172_13788011.1202767737757
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

That's exactly the intended use for RpcServlet. Great example!

On Feb 11, 2008 2:04 PM, Dan Lester <dan@danlester.com> 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>
> );
>      $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:etnu@google.com]
> Sent: 11 February 2008 19:58
> To: Dan Lester
> Cc: shindig-dev@incubator.apache.org
> Subject: Re: Getting Gadget Info without rendering gadget
>
>
> On Feb 11, 2008 11:23 AM, Dan Lester <dan@danlester.com> 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
>
>

------=_Part_7172_13788011.1202767737757--