Certainly -- could you explain what parts you need clarification on? I probably take it for granted that I know the details of gadgets, open social, and shindig all very well, so you'll have to forgive me if I make too great of assumptions about your familiarity with these projects. (not taking this off list because I think it will benefit more people who are just observing).
~Kevin On Jan 28, 2008 12:05 AM, Akash Xavier <[EMAIL PROTECTED]> wrote: > Kevin, > Could u please explain your post in simpler words? > > On Jan 27, 2008 11:31 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > Right now you'd have to implement your own opensocial-0.x (recommend 0.7 > ) > > and drop it into the features/ directory before building. > > > > As I've mentioned on previous threads, getting a real usable > > implementation > > of opensocial-0.6 / 0.7 that easily integrates with existing sites is a > > top > > priority for the project. Currently the closest thing that we have are > > copies of the references (which I believe are actually out of date -- > > possibly pre-0.6 release). > > > > Notable areas where work needs to be done: > > > > - Implement opensocial-0.7 javascript to use either container mediated > > (call > > through gadgets.rpc to the parent page) or container facilitated (issue > > requests to some new servlet via XHR, signed using the GadgetSigner > > interface tokens). I'm *strongly* in favor of the second approach for > > performance reasons. > > > > - Improve dependency injection points in GadgetServer and various > servlets > > so that you can load your own implementations via configuration. > > > > To make this work on a real site, you're going to have to do the > > following: > > > > 1. Implement GadgetSigner to generate an encrypted token that contains > > whatever you use to identify users on your site. At a minimum you should > > probably pass: > > > > - The current viewer's id > > - The "owner" of the gadget's id > > - Some way to identify the gadget itself (the url should suffice) > > - The instance id (possibly not relevant if your site doesn't allow > > multiple > > copies of the same gadget to be installed) > > - An expiration date. > > > > Since this is all very much implementation specific, I can't say what > the > > best way to pass the data for your particular site is. > > > > 2. When generating iframes for gadgets, pass t=<value of > > GadgetToken.toSerialForm()> in the hash part (i.e. url= > > http://example.org/&up_foo=bar#t=token) > > > > 3. Create a servlet filter so that you can pass appropriate data to the > > servlets (such as instances of your custom implementations of > > GadgetSigner, > > GadgetDataCache, and/or RemoteContentFetcher) > > > > You'll probably want to get the meta data from gadgets by calling > > GadgetServer.process and passing the context as RequestContext.CONTAINER > . > > This will automatically provide the container side javascript you need > to > > load as well as the meta data that would normally be unavailable. If you > > can't actually link against the library directly in your site that > > generates > > the iframes (perhaps because you're not using one of the supported > > languages), you'll probably need to wait until we have implemented the > > JsonRpcServlet discussed here: > > https://issues.apache.org/jira/browse/SHINDIG-25 > > > > ~Kevin > > > > On Jan 27, 2008 7:35 PM, Akash Xavier <[EMAIL PROTECTED]> wrote: > > > > > Hi guys > > > > > > I have this confusion. > > > Shindig can be downloaded and implemented easily. Thats fine. > > > But how do I connect my data to Shindig, so that when an opensocial > > > function > > > (example a person data is requested) the data is returned. How do I > tell > > > shindig that my data is here? > > > > > > -- > > > Akash Manohar > > > [EMAIL PROTECTED] > > > > > > > > > -- > Akash Manohar > [EMAIL PROTECTED] >
