Some hopefully useful answers inline... On Thu, Nov 08, 2007 at 12:36:53AM -0000, Mr-Yellow wrote: > > So this is what I can figure out so far..... > > [b]OpenSocial Server[/b] - No libraries available, spec not official > yet, protocol that speaks gData over AtomPub/RSS/Atom
Right, this is the RESTful API that has my hopes high. If everyone implements this we all win. > [b]OpenSocial Client[/b] - Javascript library which exposes OpenSocial > API for communication with OpenSocial backend providers (myspace, > facebook etc). Internally we're calling this the 'container' code. This is code that takes the opensocial.* calls, translates them into backend data requests and feeds it back to the the gadget/app. In the long run if a server standardized on the backend protocol this could be a single code base. > [b]Google Gadget API[/b] - Required to implement Google Gadgets on > your site. No library to translate Google Gadgets into HTML/Javascript > with hooks for backend that I can see....... Does this have to be > custom implemented by anyone wishing to support OpenSocial on their > social network site? This API also includes integrated javascript > libraries, does the social site provider also need to impletement > these in their own way? There's not much here. You need a proxy, and a method of turning the google gadget xml file into an iframe. One open question revolves around the google gadget libraries that are in common use. For example, data fetch, inline frame resizing and prefs are all defined for google gadgets. A 'pure' Open Social container would not have these methods, or would have to write their own implementation. For now hi5 is injecting the opensocial javascript libraries, stripping off the <Requires tag> and passing everything over to gmodules.com so we can get the benefit of all the existing Google Gadgets features. > [b]gData[/b] - Extension of ATOM for some reason...... Needs to be > implemented by the backend so it can talk OpenSocial...... Think using > gData might be a mistake, already the CakePHP developers are skipping > writting a wrapper for it as it's not an open standard..... 90% of > this is pretty open, cept for the parts that lock u into googles way > of working, this could be a big mistake if the market doesn't accept > it. From my POV it feels like you're trying to take over major parts > of my backend with proprietry stuff by stealth via open stuff, which > leaves me nervious that you may someday take away or change these > parts. Can understand Google wanting to work with these formats > internally, and understand it is a legit extension of Atom, however > that doesn't mean you'll get code written for it by neo-fanboy types. Atom is meant to be extensible, so I don't see what's the big deal. Semantically it seems an awkward fit for some of the data being passed around. However it does have one advantage in that you can fetch feed data of users, activity and friends in a single combined stream, along with posting requests using GET requests which allows for cross-site flexibility with javascript.... > > 1. User gives Provider a URL to Google Gadget API XML file. Maybe, however most containers are going to want to approve any app they allow to run in their environment. > 2. Provider parses Google Gadget and generates an iframe using > innerHTML from the content of the google gadget. Does this iframe load > from Authors domain or is it inline straight from the gadget contents > into the iframe innerHTML? Where are the XSS issues in this? In our case the iframe loads from gmodules.com with the URL pointing at our xml-rewriting/javascript injecting proxy. We also pre-inject the owner/viewer in the bookmark/hash portion of the iframe URL. Gross, but that's how this works.... There are XSS issues if you serve up the iFrame from the same domain as the containing page. This was the problem with Ning implementation earlier this week. If you have multiple gadgets on the same page you'll also want to serve up each from a unique url as well.. > 3. Gadgets Javascript queries Provider via OpenSocial for friends list > etc. Provider has their API exposed in OpenSocial REST/AtomPub format > (not completed/fully released). Yes and no. Right now the hi5 container grabs a public FOAF file to get profile information and friends. We will likely use existing atom feeds for activity, at least until we can get the new protocol in place on our api servers. > Which leaves me with questions........ > > What is the context that the javascript runs in? Which domain (author/ > provider)? How is it included? When/how is it checked for exploits? > Are most functions not available except for specially provided > Javascript functions as part of Google Gadgets API? It's just javascript/html, so the skies the limit here. Containers can (and may) check your XML definition for certain things. What exploits would you check for? > When integrating OpenSocial support on a social site which are the > minimum technologies? Does the developer need to implement Google > Gadget API including it's Javascript libs? The opensocial part is easy > enough and will be easier with some helper libraries. The gadget > markup iframe stuff seems like a bit of a job. You don't need to implement the iGoogle APIs, but I suspect that many app writers will want them.. Right, that's why we're routing hi5 containter requests through gmodules.com for this very reason. > Does each social site provider need to implement their own security > filters to check for rogue javascript? Yes, or containers need to establish relationships with application providers where there's a degree of trust. > Will it become easier to implement Google Gadget API? Currently it > seems like a matter of coding the whole thing from scratch rather then > just hooking backend into existing gadget->iframe parsers. I hope so... Now if I could just say "go go OpenGadget libraries" and have it all appear :) -- Paul Lindner hi5 Architect [EMAIL PROTECTED]
pgpsuxCF1IbRm.pgp
Description: PGP signature
