On Tue, May 13, 2008 at 10:21 PM, steve heron <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On Tue, May 13, 2008 at 2:58 PM, Tim Thelin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > > On Tue, May 13, 2008 at 2:38 PM, Erin Hoffmann < > [EMAIL PROTECTED]> > > > > 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 > > > > > > > > > > > > > > >
