On Thu, Nov 08, 2007 at 12:57:45AM -0800, Tony Stubblebine wrote: > > Paul, you guys are awesome! > > Piecing together what I saw in the code and your blog post, I have two > questions. > > * Is the primary job of a container to provide javascript that > implements. the openSocial.container API? I saw that you read in a > gadget and replace the "require opensocial-0.5" with your own hi5 > javascript. Did you write your own implementation of > openSocial.container because Google doesn't have a default > implementation or just because you needed to adapt it to your existing > APIs?
If I left in the 'require opensocial-0.5' code then gmodules.com would
likely add in the Orkut javascript during it's injection phase. This
is important as we're piggybacking off their service to provide ours.
Long term I believe that each container will implement their own
iframe creater/proxy/iGoogle compatible calls.
> * I saw in your blog post, but not in the code, that you pre-process
> the gadget and then pass it off to gmodules.com. Is this right? And if
> it is, is it a requirement or could you conceivably process the gadget
> yourself? (for rookies like me, the gadget/widget is an XML document
> and needs to be converted into an html/js snippit so it can actually
> be displayed)
Yes, we could preprocess it ourselves. That would involve
implementing the items mentioned above (iframe creator/proxy/iGoogle
compatibility, etc.)
Here's the flow:
1) User clicks on gallery item or submits gadget XML
2) Browser grabs XML file through local proxy to inspect it.
3) If content-type is "html-inline" stuff the content directly into
the page. You're done, gadget uses existing context
If the content-type is "html" then the following steps are
performed:
* Inject Iframe into the existing page with a source that looks
something like this:
http://0.gmodules.com/ifr?url=http://sandbox.hi5.com/friend/proxy/REALURLHERE#STATE
This tells gmodules to process the XML, but only after it's been
run through the XML rewrite/js injection phase at hi5.
* The STATE data after the hash/fragment portion of the URL above is
important, it allows our container page to pass along the owner
and viewer to the child iframe, without requiring
a round trip to the backend server.
It's easily retrieved as 'document.location.hash', see hi5profile.js.
Right now this is just escaped json data, which may or may not
have privacy/security implications.
--
Paul Lindner
hi5 Architect
[EMAIL PROTECTED]
pgp2yPsEt7m4I.pgp
Description: PGP signature
