So I came to a conclusion. Use Apache Shindig. I just browsed the features directory in the SVN and looks like some serious work is going on. (but the php version is dry). Maybe is a few days I will even post about getting Shindig running for your site.
End this topic here Bye and have a nice time with Shindig. :) On Jan 27, 8:24 pm, alphalouis <[EMAIL PROTECTED]> wrote: > Now I got some information from Brian. > I got to know why OAuth is being Implemented. > Have you seen on Facebook? whenever you access an app, you are asked > whether you want the app to access your personal data? Yeah thats what > OAuth is meant for. Its like an authorising agent that asks users > whether they want to allow the gadget to access their personal data. > Example: If a gadget lists your friends. Then before accessing the > gadget you will be asked whether you want the gadget to access the > friends data. > Right? > > On Jan 27, 8:11 pm, alphalouis <[EMAIL PROTECTED]> wrote: > > > (I didn't complete the previous message. here is the rest of the > > message).... > > > 2.) I need to take the javascript files and mess with them so that > > when a function requesting data from my site is called, it should get > > the data. I mean.... I need to change or add some variables... right? > > (I don't know... just asking you..) > > > 3.) Implement some extras like the tabs feature so that you can also > > support a few Google Gadgets feature. This implmentation of Tabs and > > other features can be done thru the <require> tag (The google gadgets > > way). And implementing extras.... like Caja etc. I don't know how to > > do it. If anyone can say it would be nice. > > > There was once a post on the Shindig mailing list titled "How Shindig > > works" > > Here's Kevin's reply in the mailing list. > > > " > > Step 1: Fetch the gadget spec XML. This *should* consult a cache > > first, to > > minimize load on the gadget author's HTTP server. The spec does not > > say how > > long to cache for (suggest 24 hours or less), but we do require that > > you > > support bypassing / clearing the cache on your server somehow. The PHP > > implementation should support the "nocache=1" query parameter to be > > compatible with Java. Relevant Java classes: GadgetServer, > > RemoteContentFetcher, GadgetDataCache > > > Step 2: Process the gadget spec. This is hard, especially since the > > spec > > hasn't been published yet (it will be later this week, I'm told). I > > would > > strongly recommend using SimpleXML and follow the same processing > > pattern as > > you'll see in GadgetSpecParser. SimpleXML should make this pretty > > easy, and > > you won't have to go through the pain of all that DOM nastiness that > > our > > Java implementation had to deal with. Relevant Java classes: > > GadgetSpecParser, GadgetSpec > > > Step 3: Fetch message bundles. These are fetched by inspecting the > > <Locale> > > tags in the spec and making http requests for the bundle files. You > > should > > get your locale from the "lang" and "country" query parameters. > > Processing > > rules for locales have a few caveats, so examine > > MessageBundleSubstituter > > carefully and emulate that behavior. The actual messagebundle spec is > > extremely simple. Message bundles should be cached using the same > > caching > > policy as Step #1. Relevant classes: MessageBundle, > > MessageBundleParser, > > MessageBundleSubstituter > > > Step 4: Perform hangman variable substitutions. This is done by > > replacing > > __UP, __MSG, __MODULE, and other placeholders with other values. You > > should > > perform these substitutions in the following order: > > > __MSG > > __BIDI > > __MODULE > > __UP > > > MSG and UP need to be html escaped to prevent XSS attacks. BIDI is a > > set of > > constants (see BidiSubstituter or the spec, whenever it gets > > published, for > > details). __MODULE only has one possible value right now: > > __MODULE_ID__, > > which is the "mid" query parameter (an UNSIGNED integer). Only do a > > single > > pass for each substitution type (you can use either a regex, or > > implement a > > basic parser like we did), and do not revist types already processed > > (i.e. > > don't substitute __MSG after you've already done __UP). Relevant > > classes: > > Substitutions, MessageBundleSubstituter, BidiSubstituter, > > ModuleSubstituter, > > UserPrefsSubstituter > > > Step 5: Process <Require> / <Optional> features. This is going to be > > hard to > > do right now without the spec. We will be publishing this shortly, but > > what > > you see in shindig right now is, for the most part, the complete set > > of what > > will be in the initial "mandatory" support list. The good news is that > > most > > of this work is already done for you. You need to implement support > > for > > feature.xml loading and proper handling of <dependency>. See > > trunk/features/README for details on the file format, and look at > > JsFeatureLoader for an implementation. Combine this with the > > dependency > > graph resolution in GagdetFeatureRegistry.getIncludedFeatures and you > > should > > be good to go. Relevant classes: GadgetFeatureRegistry, JsFeature, > > JsFeatureLoader > > > Step 6: Output gadget content. The order is as follows: > > > - standard html header (an ugly inline version can be seen in > > GadgetRenderingServlet. This will be a lot cleaner in a PHP template). > > Replicate this exactly for now (even the lack of a DOCTYPE). > > - feature libraries (separate scripts, or ideally rolled up into a > > single > > file or script block like we do in GadgetRenderingServlet) > > - Initialization of feature libraries (currently only gadgets.ifpc_, > > gadgets.Prefs, and gadgets.io need this) > > - processed gadget code from step 4. > > - a single call to gadgets.util.runOnLoadHandlers > > - close your html > > > Ideally, all of the output from step 6 (except the html body wrapper) > > should > > be passed through Caja, but right now that's going to be difficult to > > do in > > PHP. Don't worry about it for now, I'll have a solution for you > > shortly. > > > This implements what we have on gmodules.com. Ideally, everything up > > to and > > including step 5 should be able to be done directly from some library > > similar to GadgetProcessor, and the wrapper of Step 6 should happen in > > the > > code that specifically handles outputting iframe content. I *strongly* > > recommend using curl_multi in implementing containers to fetch all of > > the > > gadget data in parallel, then caching that so that when the iframes > > load, > > they will be loading entirely from cache (which will be fast). This is > > really the only part of the whole pipeline that needs to be run in > > parallel, > > due to the fact that http fetching is slow. " > > > So thats just a hint for everyone else (I didn't understand most of > > it). > > So can anyone explain it clearly on How to do it in PHP? > > > I hope this topic helps others who want to do it on their own. > > > -- > > Eagerly waiting for your replies! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Implementing OpenSocial Containers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-container?hl=en -~----------~----~----~----~------~----~------~--~---
