You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Erin Hoffmann <eh...@linkedin.com> on 2008/05/13 23:38:28 UTC
The gadget metadata service
Hello,
I am trying to understand better how to use the gadget metadata service. I
want to invoke the metadata service from my container page in order to fetch
the user preference metadata and the gadget default title. Looking at
sample-metadata.html and RpcServlet.java, it appears that the only way to
request metadata is via an XHR post. This means the request needs to
originate from the same domain the gadget server is on.
Unfortunately, my container page is on a different domain than my gadget
server. Can anyone provide me some guidance as to how to do what I want to
do? Invoking the metadata service from within the gadget iframe doesn't
make a lot of sense from a lot of different perspectives. Invoking it from
the container is currently impossible when the container and gadget server
are on different domains.
Am I thinking about this the right way? Any help is appreciated.
Thanks,
Erin
Re: The gadget metadata service
Posted by steve heron <st...@gmail.com>.
sorry, Kevin,
posted that before I saw your reply. So I'm thinking that the
authentication may be a bigger hurdle than I'd anticipated. I'll have
to study the implications some more.
thanks
steve
On Wed, May 14, 2008 at 9:17 AM, steve heron <st...@gmail.com> wrote:
> Hi Brian,
> The short answer is I don't know, on either count. Perhaps if I may
> explain what I intend to try, and there are false assumptions in my
> approach, we can expose them now. To date, I've been following various
> threads on this group, which have informed my understanding and led me
> to believe that what I describe below is possible.
> My application is a client-side portal-type framework with
> infrastructure for layout management, user preference dialogs,
> persistence of user prefs etc. I want to make shindig/gadget content
> available within this container. (At the moment I have no requirement
> for open social data I just want to leverage the gadget infrastructure,
> although it would be a logical next step to make opensocial services
> available too).
>
> When I load a 'page' I will know whether this contains any shindig
> content - I would make a request to shindig for the metadata for any
> such gadgets. This will give me the info I need to render the chrome and
> display the appropriate userprefs dialog. I will create the iframe and
> combine the iframe url from the metadata server with the persisted
> userprefs that my container has loaded and let shindig populate the
> iframe.
> Obviously if my 'pages' consisted primarily of shindig-hosted content,
> then the calls to the metadata service would impose an overhead that a
> purely serverside implementation would not incur. This is unlikely to be
> the case, however - I expect the shindig content to be supplemental to
> the main content of the app. In addition, I would hope to employ some
> sort of caching of the metadada if at all possible, so that just as
> shindig will cache the xml spec, further downstream I would cache the
> metadata generated from that spec (I stress 'if possible' - I haven't
> investigated what obstacles this may present).
>
> As far as gadget data is concerned - I had supposed that provided I
> composed the iframe url correctly, then that would provide all the
> information that shindig required to prepopulate the constructed gadget
> with the appropriate data ? I have to confess, my experiments so far
> have been with very simple gadgets which either fetch their own data or
> don't require any. I had also supposed that I will be able to use the
> opensocial restful apis (both allow gadgets to use them and even allow
> the container itself to load data on behalf of gadgets) from the client,
> should I subsequently opt to expose some opensocial functionality.
>
> Authentication is another matter. I honestly don't know how this will
> work and am hoping that one of the things I will gain from this
> experiment is a) an understanding of how shindig implements
> authentication and b) an understanding of how I should implement the
> same for my own framework. Before now, I have only ever built/deployed
> corporate apps running behind proprietary/internal SSO systems and
> adapted each implementation of the framework to the security needs of
> each app. I very much want to implement an open , generic authentication
> mechanism for the fw and am hoping my experience with shindig will give
> me some ideas how to do that.
>
> I have seen advice given previously on this list regarding using the
> metadata service from the client, which was why I assumed this was a
> valid approach. I'd hate to think I'm sneaking data through the back
> door, and may see that door closed in some future release. It was the
> comment that this was not the intended use of this service that set
> alarm bells ringing here.
>
> Sorry to bore you with such a long post, but it would be good (for
> others beside myself, I believe) to establish that such a
> 'client-centric' approach represents a valid use (rather than abuse) of
> shindig services.
>
> Thanks
>
> Steve heron
>
> On Wed, May 14, 2008 at 6:27 AM, Brian Eaton <be...@google.com> wrote:
>> On Tue, May 13, 2008 at 10:21 PM, steve heron <st...@gmail.com> wrote:
>>>I am also integrating shindig generated
>>> content into a purely client-side container.
>>
>> How are you authenticating users and getting them data?
>>
>
Re: The gadget metadata service
Posted by steve heron <st...@gmail.com>.
Hi Brian,
The short answer is I don't know, on either count. Perhaps if I may
explain what I intend to try, and there are false assumptions in my
approach, we can expose them now. To date, I've been following various
threads on this group, which have informed my understanding and led me
to believe that what I describe below is possible.
My application is a client-side portal-type framework with
infrastructure for layout management, user preference dialogs,
persistence of user prefs etc. I want to make shindig/gadget content
available within this container. (At the moment I have no requirement
for open social data I just want to leverage the gadget infrastructure,
although it would be a logical next step to make opensocial services
available too).
When I load a 'page' I will know whether this contains any shindig
content - I would make a request to shindig for the metadata for any
such gadgets. This will give me the info I need to render the chrome and
display the appropriate userprefs dialog. I will create the iframe and
combine the iframe url from the metadata server with the persisted
userprefs that my container has loaded and let shindig populate the
iframe.
Obviously if my 'pages' consisted primarily of shindig-hosted content,
then the calls to the metadata service would impose an overhead that a
purely serverside implementation would not incur. This is unlikely to be
the case, however - I expect the shindig content to be supplemental to
the main content of the app. In addition, I would hope to employ some
sort of caching of the metadada if at all possible, so that just as
shindig will cache the xml spec, further downstream I would cache the
metadata generated from that spec (I stress 'if possible' - I haven't
investigated what obstacles this may present).
As far as gadget data is concerned - I had supposed that provided I
composed the iframe url correctly, then that would provide all the
information that shindig required to prepopulate the constructed gadget
with the appropriate data ? I have to confess, my experiments so far
have been with very simple gadgets which either fetch their own data or
don't require any. I had also supposed that I will be able to use the
opensocial restful apis (both allow gadgets to use them and even allow
the container itself to load data on behalf of gadgets) from the client,
should I subsequently opt to expose some opensocial functionality.
Authentication is another matter. I honestly don't know how this will
work and am hoping that one of the things I will gain from this
experiment is a) an understanding of how shindig implements
authentication and b) an understanding of how I should implement the
same for my own framework. Before now, I have only ever built/deployed
corporate apps running behind proprietary/internal SSO systems and
adapted each implementation of the framework to the security needs of
each app. I very much want to implement an open , generic authentication
mechanism for the fw and am hoping my experience with shindig will give
me some ideas how to do that.
I have seen advice given previously on this list regarding using the
metadata service from the client, which was why I assumed this was a
valid approach. I'd hate to think I'm sneaking data through the back
door, and may see that door closed in some future release. It was the
comment that this was not the intended use of this service that set
alarm bells ringing here.
Sorry to bore you with such a long post, but it would be good (for
others beside myself, I believe) to establish that such a
'client-centric' approach represents a valid use (rather than abuse) of
shindig services.
Thanks
Steve heron
On Wed, May 14, 2008 at 6:27 AM, Brian Eaton <be...@google.com> wrote:
> On Tue, May 13, 2008 at 10:21 PM, steve heron <st...@gmail.com> wrote:
>>I am also integrating shindig generated
>> content into a purely client-side container.
>
> How are you authenticating users and getting them data?
>
Re: The gadget metadata service
Posted by Brian Eaton <be...@google.com>.
On Tue, May 13, 2008 at 10:21 PM, steve heron <st...@gmail.com> wrote:
>I am also integrating shindig generated
> content into a purely client-side container.
How are you authenticating users and getting them data?
Re: The gadget metadata service
Posted by Kevin Brown <et...@google.com>.
On Tue, May 13, 2008 at 10:21 PM, steve heron <st...@gmail.com>
wrote:
> Hi,
> I'm a bit concerned about Kevins comment above that the metadata
> servlet is 'intended to be consumed and processed serverside' (
> despite the xhr example). I am also integrating shindig generated
> content into a purely client-side container. Is this a totally
> unforseen usage of the service ?
Not unforseen, just not viable. See further comments.
> The further comment that handling the
> chrome , iframe generation client-side is 'unwieldy, is pure opinion,
> Kevin, a javascript specialist (like myself) would see it quite the
> other way round.
You're certainly free to do things however you like, though I couldn't give
an honest recommendation to anyone to make the metadata request client side;
it can't be secure (even if you implemented crypto in client-side JS, you'd
have to pass your secrets in the clear), it can't perform well (you'll
always have an extra http request), and you're stuck embedding your markup
in javascript unless you want to incur the cost of additional http requests.
If you like javascript as much as I do, your best option is to use
server-side JS. I've done a few projects that have gone this route, and I've
been very happy with it. Wikipedia has a good reference if you're
interested: http://en.wikipedia.org/wiki/Server-side_JavaScript
Can we be assured that the metadata service will
> always be available for client consumption, if not it will make
> shindig usage for client-side containers like my own impossible.
It will certainly always be available, for the simple reason that it
operates over HTTP. It's not an approach that I would ever recommend to
someone building a web site-based container, but the nature of the project
isn't changing.
>
>
> Steve
>
> On Tue, May 13, 2008 at 11:52 PM, Kevin Brown <et...@google.com> wrote:
> > On Tue, May 13, 2008 at 2:58 PM, Tim Thelin <tt...@google.com> wrote:
> >
> > > Hi Erin,
> > >
> > > I have the same issue, and I solved it (mostly) client side. Now
> based on
> > > Kevin's response it doesn't sound like what I'm about to say is the
> > > correct
> > > way, but it does work.
> > >
> > > I used jsonp as the vehicle for getting the data instead of a raw XHR,
> as
> > > jsonp lets you get json-data cross-origin:
> > > http://ajaxian.com/archives/jsonp-json-with-padding
> > >
> > > The idea is to dynamically create a script tag pointing to /metadata,
> and
> > > you add query parameters to specify (1) the data you want back, and
> (2)
> > > the
> > > callback function you want called with the new json-formatted-metadata
> > >
> > > The only problem was that script tags get the scripts using GET, not
> POST,
> > > and /metadata expects a POST. So I also modified the shindig gadget
> > > server
> > > to accept a GET to /metadata, making it do the same exact thing as the
> > > POST
> > > except to expect the args in the query params instead of post data,
> and to
> > > honor the jsonp callback.
> > >
> > >
> > > Kevin,
> > >
> > > Besides latency, is there anything inherently wrong with doing it this
> > > way?
> >
> >
> > The biggest problem is that the metadata request will likely contain
> more
> > than 2KB of data for any page with a significant number of gadgets (or
> user
> > preferences), and JSONP won't work for GET requests that need more than
> > that.
> >
> > This approach also requires you to do all of the gadget "chrome" and
> iframe
> > generation in javascript, which is unwieldy compared to server-side
> > templating solutions like PHP or whatnot.
> >
> >
> >
> >
> > >
> > >
> > > -Tim
> > >
> > > On Tue, May 13, 2008 at 2:48 PM, Kevin Brown <et...@google.com> wrote:
> > >
> > > > On Tue, May 13, 2008 at 2:38 PM, Erin Hoffmann <
> ehoffmann@linkedin.com>
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I am trying to understand better how to use the gadget metadata
> > > service.
> > > > > I
> > > > > want to invoke the metadata service from my container page in
> order to
> > > > > fetch
> > > > > the user preference metadata and the gadget default title.
> Looking at
> > > > > sample-metadata.html and RpcServlet.java, it appears that the only
> way
> > > > to
> > > > > request metadata is via an XHR post. This means the request needs
> to
> > > > > originate from the same domain the gadget server is on.
> > > > >
> > > > > Unfortunately, my container page is on a different domain than my
> > > gadget
> > > > > server. Can anyone provide me some guidance as to how to do what
> I
> > > want
> > > > > to
> > > > > do? Invoking the metadata service from within the gadget iframe
> > > doesn't
> > > > > make a lot of sense from a lot of different perspectives.
> Invoking it
> > > > > from
> > > > > the container is currently impossible when the container and
> gadget
> > > > server
> > > > > are on different domains.
> > > > >
> > > > > Am I thinking about this the right way? Any help is appreciated.
> > > >
> > > >
> > > > The metadata servlet is intended to be consumed and processed
> > > server-side,
> > > > before you emit your output html. The sample page uses XHR in order
> to
> > > > remain implementation neutral. If your parent page was in PHP, you
> could
> > > > do
> > > > something like the following:
> > > >
> > > > $request = json_encode('gadgets'=>array('...'),
> > > 'context'=>array('...'));
> > > > $curl = curl_init();
> > > > ...various curl setup operations...
> > > > $data = json_decode(curl_exec($curl));
> > > >
> > > > foreach ($data['gadgets'] as $gadget) {
> > > > echo '<h2>'.htmlentities($gadget['title']).'</h2>';
> > > > echo '<iframe src="...
> > > > }
> > > >
> > > > Similar techniques can be used in python, perl, ruby, java, or
> whatever
> > > > language you like. I'd definitely not recommend doing this client
> side,
> > > if
> > > > for nothing else than to avoid additional end-user latency.
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > > Erin
> > > > >
> > > >
> > >
> >
>
Re: The gadget metadata service
Posted by steve heron <st...@gmail.com>.
Hi,
I'm a bit concerned about Kevins comment above that the metadata
servlet is 'intended to be consumed and processed serverside' (
despite the xhr example). I am also integrating shindig generated
content into a purely client-side container. Is this a totally
unforseen usage of the service ? The further comment that handling the
chrome , iframe generation client-side is 'unwieldy, is pure opinion,
Kevin, a javascript specialist (like myself) would see it quite the
other way round. Can we be assured that the metadata service will
always be available for client consumption, if not it will make
shindig usage for client-side containers like my own impossible.
Steve
On Tue, May 13, 2008 at 11:52 PM, Kevin Brown <et...@google.com> wrote:
> On Tue, May 13, 2008 at 2:58 PM, Tim Thelin <tt...@google.com> wrote:
>
> > Hi Erin,
> >
> > I have the same issue, and I solved it (mostly) client side. Now based on
> > Kevin's response it doesn't sound like what I'm about to say is the
> > correct
> > way, but it does work.
> >
> > I used jsonp as the vehicle for getting the data instead of a raw XHR, as
> > jsonp lets you get json-data cross-origin:
> > http://ajaxian.com/archives/jsonp-json-with-padding
> >
> > The idea is to dynamically create a script tag pointing to /metadata, and
> > you add query parameters to specify (1) the data you want back, and (2)
> > the
> > callback function you want called with the new json-formatted-metadata
> >
> > The only problem was that script tags get the scripts using GET, not POST,
> > and /metadata expects a POST. So I also modified the shindig gadget
> > server
> > to accept a GET to /metadata, making it do the same exact thing as the
> > POST
> > except to expect the args in the query params instead of post data, and to
> > honor the jsonp callback.
> >
> >
> > Kevin,
> >
> > Besides latency, is there anything inherently wrong with doing it this
> > way?
>
>
> The biggest problem is that the metadata request will likely contain more
> than 2KB of data for any page with a significant number of gadgets (or user
> preferences), and JSONP won't work for GET requests that need more than
> that.
>
> This approach also requires you to do all of the gadget "chrome" and iframe
> generation in javascript, which is unwieldy compared to server-side
> templating solutions like PHP or whatnot.
>
>
>
>
> >
> >
> > -Tim
> >
> > On Tue, May 13, 2008 at 2:48 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > On Tue, May 13, 2008 at 2:38 PM, Erin Hoffmann <eh...@linkedin.com>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I am trying to understand better how to use the gadget metadata
> > service.
> > > > I
> > > > want to invoke the metadata service from my container page in order to
> > > > fetch
> > > > the user preference metadata and the gadget default title. Looking at
> > > > sample-metadata.html and RpcServlet.java, it appears that the only way
> > > to
> > > > request metadata is via an XHR post. This means the request needs to
> > > > originate from the same domain the gadget server is on.
> > > >
> > > > Unfortunately, my container page is on a different domain than my
> > gadget
> > > > server. Can anyone provide me some guidance as to how to do what I
> > want
> > > > to
> > > > do? Invoking the metadata service from within the gadget iframe
> > doesn't
> > > > make a lot of sense from a lot of different perspectives. Invoking it
> > > > from
> > > > the container is currently impossible when the container and gadget
> > > server
> > > > are on different domains.
> > > >
> > > > Am I thinking about this the right way? Any help is appreciated.
> > >
> > >
> > > The metadata servlet is intended to be consumed and processed
> > server-side,
> > > before you emit your output html. The sample page uses XHR in order to
> > > remain implementation neutral. If your parent page was in PHP, you could
> > > do
> > > something like the following:
> > >
> > > $request = json_encode('gadgets'=>array('...'),
> > 'context'=>array('...'));
> > > $curl = curl_init();
> > > ...various curl setup operations...
> > > $data = json_decode(curl_exec($curl));
> > >
> > > foreach ($data['gadgets'] as $gadget) {
> > > echo '<h2>'.htmlentities($gadget['title']).'</h2>';
> > > echo '<iframe src="...
> > > }
> > >
> > > Similar techniques can be used in python, perl, ruby, java, or whatever
> > > language you like. I'd definitely not recommend doing this client side,
> > if
> > > for nothing else than to avoid additional end-user latency.
> > >
> > >
> > > >
> > > > Thanks,
> > > > Erin
> > > >
> > >
> >
>
Re: The gadget metadata service
Posted by Kevin Brown <et...@google.com>.
On Tue, May 13, 2008 at 2:58 PM, Tim Thelin <tt...@google.com> wrote:
> Hi Erin,
>
> I have the same issue, and I solved it (mostly) client side. Now based on
> Kevin's response it doesn't sound like what I'm about to say is the
> correct
> way, but it does work.
>
> I used jsonp as the vehicle for getting the data instead of a raw XHR, as
> jsonp lets you get json-data cross-origin:
> http://ajaxian.com/archives/jsonp-json-with-padding
>
> The idea is to dynamically create a script tag pointing to /metadata, and
> you add query parameters to specify (1) the data you want back, and (2)
> the
> callback function you want called with the new json-formatted-metadata
>
> The only problem was that script tags get the scripts using GET, not POST,
> and /metadata expects a POST. So I also modified the shindig gadget
> server
> to accept a GET to /metadata, making it do the same exact thing as the
> POST
> except to expect the args in the query params instead of post data, and to
> honor the jsonp callback.
>
>
> Kevin,
>
> Besides latency, is there anything inherently wrong with doing it this
> way?
The biggest problem is that the metadata request will likely contain more
than 2KB of data for any page with a significant number of gadgets (or user
preferences), and JSONP won't work for GET requests that need more than
that.
This approach also requires you to do all of the gadget "chrome" and iframe
generation in javascript, which is unwieldy compared to server-side
templating solutions like PHP or whatnot.
>
>
> -Tim
>
> On Tue, May 13, 2008 at 2:48 PM, Kevin Brown <et...@google.com> wrote:
>
> > On Tue, May 13, 2008 at 2:38 PM, Erin Hoffmann <eh...@linkedin.com>
> > wrote:
> >
> > > Hello,
> > >
> > > I am trying to understand better how to use the gadget metadata
> service.
> > > I
> > > want to invoke the metadata service from my container page in order to
> > > fetch
> > > the user preference metadata and the gadget default title. Looking at
> > > sample-metadata.html and RpcServlet.java, it appears that the only way
> > to
> > > request metadata is via an XHR post. This means the request needs to
> > > originate from the same domain the gadget server is on.
> > >
> > > Unfortunately, my container page is on a different domain than my
> gadget
> > > server. Can anyone provide me some guidance as to how to do what I
> want
> > > to
> > > do? Invoking the metadata service from within the gadget iframe
> doesn't
> > > make a lot of sense from a lot of different perspectives. Invoking it
> > > from
> > > the container is currently impossible when the container and gadget
> > server
> > > are on different domains.
> > >
> > > Am I thinking about this the right way? Any help is appreciated.
> >
> >
> > The metadata servlet is intended to be consumed and processed
> server-side,
> > before you emit your output html. The sample page uses XHR in order to
> > remain implementation neutral. If your parent page was in PHP, you could
> > do
> > something like the following:
> >
> > $request = json_encode('gadgets'=>array('...'),
> 'context'=>array('...'));
> > $curl = curl_init();
> > ...various curl setup operations...
> > $data = json_decode(curl_exec($curl));
> >
> > foreach ($data['gadgets'] as $gadget) {
> > echo '<h2>'.htmlentities($gadget['title']).'</h2>';
> > echo '<iframe src="...
> > }
> >
> > Similar techniques can be used in python, perl, ruby, java, or whatever
> > language you like. I'd definitely not recommend doing this client side,
> if
> > for nothing else than to avoid additional end-user latency.
> >
> >
> > >
> > > Thanks,
> > > Erin
> > >
> >
>
Re: The gadget metadata service
Posted by Tim Thelin <tt...@google.com>.
Hi Erin,
I have the same issue, and I solved it (mostly) client side. Now based on
Kevin's response it doesn't sound like what I'm about to say is the correct
way, but it does work.
I used jsonp as the vehicle for getting the data instead of a raw XHR, as
jsonp lets you get json-data cross-origin:
http://ajaxian.com/archives/jsonp-json-with-padding
The idea is to dynamically create a script tag pointing to /metadata, and
you add query parameters to specify (1) the data you want back, and (2) the
callback function you want called with the new json-formatted-metadata
The only problem was that script tags get the scripts using GET, not POST,
and /metadata expects a POST. So I also modified the shindig gadget server
to accept a GET to /metadata, making it do the same exact thing as the POST
except to expect the args in the query params instead of post data, and to
honor the jsonp callback.
Kevin,
Besides latency, is there anything inherently wrong with doing it this way?
-Tim
On Tue, May 13, 2008 at 2:48 PM, Kevin Brown <et...@google.com> wrote:
> On Tue, May 13, 2008 at 2:38 PM, Erin Hoffmann <eh...@linkedin.com>
> wrote:
>
> > Hello,
> >
> > I am trying to understand better how to use the gadget metadata service.
> > I
> > want to invoke the metadata service from my container page in order to
> > fetch
> > the user preference metadata and the gadget default title. Looking at
> > sample-metadata.html and RpcServlet.java, it appears that the only way
> to
> > request metadata is via an XHR post. This means the request needs to
> > originate from the same domain the gadget server is on.
> >
> > Unfortunately, my container page is on a different domain than my gadget
> > server. Can anyone provide me some guidance as to how to do what I want
> > to
> > do? Invoking the metadata service from within the gadget iframe doesn't
> > make a lot of sense from a lot of different perspectives. Invoking it
> > from
> > the container is currently impossible when the container and gadget
> server
> > are on different domains.
> >
> > Am I thinking about this the right way? Any help is appreciated.
>
>
> The metadata servlet is intended to be consumed and processed server-side,
> before you emit your output html. The sample page uses XHR in order to
> remain implementation neutral. If your parent page was in PHP, you could
> do
> something like the following:
>
> $request = json_encode('gadgets'=>array('...'), 'context'=>array('...'));
> $curl = curl_init();
> ...various curl setup operations...
> $data = json_decode(curl_exec($curl));
>
> foreach ($data['gadgets'] as $gadget) {
> echo '<h2>'.htmlentities($gadget['title']).'</h2>';
> echo '<iframe src="...
> }
>
> Similar techniques can be used in python, perl, ruby, java, or whatever
> language you like. I'd definitely not recommend doing this client side, if
> for nothing else than to avoid additional end-user latency.
>
>
> >
> > Thanks,
> > Erin
> >
>
Re: The gadget metadata service
Posted by Kevin Brown <et...@google.com>.
On Tue, May 13, 2008 at 2:38 PM, Erin Hoffmann <eh...@linkedin.com>
wrote:
> Hello,
>
> I am trying to understand better how to use the gadget metadata service.
> I
> want to invoke the metadata service from my container page in order to
> fetch
> the user preference metadata and the gadget default title. Looking at
> sample-metadata.html and RpcServlet.java, it appears that the only way to
> request metadata is via an XHR post. This means the request needs to
> originate from the same domain the gadget server is on.
>
> Unfortunately, my container page is on a different domain than my gadget
> server. Can anyone provide me some guidance as to how to do what I want
> to
> do? Invoking the metadata service from within the gadget iframe doesn't
> make a lot of sense from a lot of different perspectives. Invoking it
> from
> the container is currently impossible when the container and gadget server
> are on different domains.
>
> Am I thinking about this the right way? Any help is appreciated.
The metadata servlet is intended to be consumed and processed server-side,
before you emit your output html. The sample page uses XHR in order to
remain implementation neutral. If your parent page was in PHP, you could do
something like the following:
$request = json_encode('gadgets'=>array('...'), 'context'=>array('...'));
$curl = curl_init();
...various curl setup operations...
$data = json_decode(curl_exec($curl));
foreach ($data['gadgets'] as $gadget) {
echo '<h2>'.htmlentities($gadget['title']).'</h2>';
echo '<iframe src="...
}
Similar techniques can be used in python, perl, ruby, java, or whatever
language you like. I'd definitely not recommend doing this client side, if
for nothing else than to avoid additional end-user latency.
>
> Thanks,
> Erin
>