You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Paul Lindner <li...@inuus.com> on 2010/04/16 11:51:16 UTC
Rewriting gadgets.js
I've been spending some time making it easier to implement gadgets in a
container and it seems like I'm going down the path of rewriting
gadgets.js.
I'd like to hear what others have done with/to this to implement their
containers and hopefully make something that works much better.
Here's what I've done so far:
* Prototyping with jquery
* Using custom tags
* Using metadata servlet.
Here's an example of where I'm headed:
<!-- load up the container JS, include the container=default here...-->
<head>
<script type="text/javascript"
src="../../js/rpc:shindig.connect:core.js?container=default&c=1"></script>
<os:config view="home" lang="en" country="US"/>
</head>
<body onLoad="shindig.container.render()">
Hello <os:viewer attr="displayName"/> on page owned by <os:owner
attr="displayName"/>
<os:gadget moduleId="2" url="
http://www.google.com/ig/modules/horoscope.xml"></os:gadget>
<body>
The JsServlet (used in the script tag above) injects ContainerConfig and is
modified to emit container specific information including the relayUrl,
skins info, etc. This is optionally overridden in the os:config tag along
with per-request info like locale and view.
shindig.container.render() gathers the <os:gadget...> entries from the DOM,
assigns unique IDs and constructs a suitable metadata call using JSONP.
The metadata servlet is modified to return security tokens as part of the
response, and will return basic viewer/owner information too -- it can do
this since it runs on a domain where an existing user has cookie values.
The handler for the metadata response then adds the iframes to the DOM,
calls gadgets.rpc.setupReceiver() and substitutes values for os:viewer and
os:owner, and the page is displayed!
Thoughts on this as a technique? Anyone interesting in working with me on
this?
One very intriguing possibility is running the metadata servlet on a central
host and allowing anyone to syndicate the entire system by creating a
container for each partner that wants access to the users on that central
host.
Re: Rewriting gadgets.js
Posted by Tim Wintle <ti...@teamrubber.com>.
(I've got a shipping deadline today so sending comments on what I've
read)
On Tue, 2010-04-27 at 08:09 -0700, Paul Lindner wrote:
> I think you need to checkout the connect branch
Spot on, looks like `git merge origin/connect` has pulled the correct
changes.
> Are you running this on windows? I seem to remember that there were
> some issues with yui on that platform.
linux -I use the yuicompressor jar regularly so was surprised - I'm
assuming just a configuration option on my system somewhere but it
doesn't matter for now.
Regarding the code:
It seem to be missing two gadgets (login.xml, share.xml) are missing
from git, and I had to substitute a different gadget to preview the
canvas.
It's looking far easier to do a basic integration - in particular I'm
thinking of:
* Our internal gadget testing environment (which is static)
* Syndicating onto third party domains (as you mentioned)
I would still have had to re-write the container javascript from scratch
for my most important container though (essentially an enterprise
dashboard system).
I think loading the canvas in a layer is essential for the second
situation, but would be the first thing to go in my main container.
I couldn't get the gadgets to refresh after the dom has loaded, the
shindig object seems to be undefined when I poke around in firebug. I
think having a fully featured javascript api available would be
essential.
Generating the layout seems to have been abstracted away from gadgets.js
and into the hands of the developer - I think that's probably a good
thing, as long as there is a good js api around the container
javascript.
Although I see the appeal of it, I'm not sure I personally would use the
templating system because I'm wouldn't fit so nicely with my existing
code - I'm not sure how many third-party developers would either as it
feels like another language to have to work with (given that third party
devs might not have experience with writing gadget xml).
Could the template based api be separated from the javascript api, so
the template api had a dependency on the javascript api, and the
developer could choose a method to use?
I'm also assuming it would be re-written to not use jQuery, but thought
it was worth asking.
Tim Wintle
Re: Rewriting gadgets.js
Posted by Paul Lindner <li...@inuus.com>.
I think you need to checkout the connect branch
git checkout connect
then re-execute the mvn/mvn -Prun
Are you running this on windows? I seem to remember that there were some
issues with yui on that platform.
On Tue, Apr 27, 2010 at 7:40 AM, Tim Wintle <ti...@teamrubber.com>wrote:
> On Tue, 2010-04-27 at 06:46 -0700, Paul Lindner wrote:
> > I've put my experimental gadgets.js rewrite code on github at
>
> > http://github.com/lindner/shindig/commits/connect
> >
> >
> > To try it out use:
> > mvn
> > mvn -Prun
> > http://localhost:8080/connect/page.html
>
> I'm getting a fatal error from yuicompressor during the build - it's the
> first time I've built the java version in a while so could easily be my
> fault.
>
> Removing the yuicompressor <execution> from features/pom.xml I can build
> the war - but http://localhost:8080/connect/page.html gives me a 404
> (localhost:8080 works fine)
>
>
> trace from building with YUI
>
> ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.RuntimeException
> at
>
> com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber(JavaScriptCompressor.java:299)
> at
>
> com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:335)
> at
>
> com.yahoo.platform.yui.compressor.JavaScriptCompressor.<init>(JavaScriptCompressor.java:532)
> at
>
> net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile(YuiCompressorMojo.java:178)
> at
> ...
>
>
>
Re: Rewriting gadgets.js
Posted by Tim Wintle <ti...@teamrubber.com>.
On Tue, 2010-04-27 at 06:46 -0700, Paul Lindner wrote:
> I've put my experimental gadgets.js rewrite code on github at
> http://github.com/lindner/shindig/commits/connect
>
>
> To try it out use:
> mvn
> mvn -Prun
> http://localhost:8080/connect/page.html
I'm getting a fatal error from yuicompressor during the build - it's the
first time I've built the java version in a while so could easily be my
fault.
Removing the yuicompressor <execution> from features/pom.xml I can build
the war - but http://localhost:8080/connect/page.html gives me a 404
(localhost:8080 works fine)
trace from building with YUI
------------------------------------------------------------------------
[INFO] Trace
java.lang.RuntimeException
at
com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber(JavaScriptCompressor.java:299)
at
com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:335)
at
com.yahoo.platform.yui.compressor.JavaScriptCompressor.<init>(JavaScriptCompressor.java:532)
at
net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile(YuiCompressorMojo.java:178)
at
...
Re: Failed secure makeRequest
Posted by ヨンニ ベリィストロム <jo...@unigent.jp>.
I don't mind monologs :-)
I sorted it out, this was the page I was looking for, explains it in a
nice way:
http://wiki.opensocial.org/index.php?title=Validating_Signed_Requests
Turned out I accidentally added an extra tab inside the public key. :-(
*slaps forehead*
ヨンニ ベリィストロム wrote:
> With PHP, I'm using the class OAuthSignatureMethod_RSA_SHA1, but the
> check_signature() function always returns false (signature failed).
> The service provider is sent these parameters:
>
> Array
> (
> [oauth_version] => 1.0
> [oauth_nonce] => e2ef1ee7a45c112680d5d835f15dbdf5
> [oauth_timestamp] => 1272453429
> [oauth_consumer_key] => default
> [opensocial_owner_id] => 1
> [opensocial_viewer_id] => 1
> [opensocial_app_id] => 1
> [opensocial_app_url] => http://theappurl/gadget.xml
> [oauth_token] =>
> [xoauth_signature_publickey] => http://newshindig/public.cer
> [xoauth_public_key] => http://newshindig/public.cer
> [oauth_signature_method] => RSA-SHA1
> [oauth_signature] => averylongstringwithrandomchars
> )
>
> oauth_token is empty, is that ok or a problem?
> Is any other required data missing?
>
>
> ヨンニ ベリィストロム wrote:
>> Not sure what you mean by the security token - but I've made some
>> progress here, it doesn't end with error anymore, and a request is
>> successfully (?) sent to the application server.
>> I haven't figured out how to sign it successfully there yet.
>>
>>
>> Evgeny Bogdanov wrote:
>>> What is the security token, that you use?
>>>
>>> On 28.04.10 10:24, ヨンニ ベリィストロム wrote:
>>>> I'm using the latest (php) Shindig/Partuza from the trunk (well, ~ 1
>>>> week old copy).
>>>>
>>>> I haven't been able to use SIGNED authorization with
>>>> gadgets.io.makeRequest.
>>>>
>>>> Unsigned works well, I'm using the JSON contenttype.
>>>>
>>>>
>>>> With signed, I tried to set up public/private key files like described
>>>> in /shindig/certs/README, I get the files and everything + add the
>>>> pass
>>>> phrase into the 'private_key_phrase' in (and local.php), but the
>>>> server
>>>> responds with error 500, "INVALID_GADGET_TOKEN".
>>>>
>>>> Could someone point me to some setup instructions?
>>>>
>>>> Thank you
>>>>
>>>> /Jonny
>>>>
>
>
>
Re: Failed secure makeRequest
Posted by ヨンニ ベリィストロム <jo...@unigent.jp>.
With PHP, I'm using the class OAuthSignatureMethod_RSA_SHA1, but the
check_signature() function always returns false (signature failed).
The service provider is sent these parameters:
Array
(
[oauth_version] => 1.0
[oauth_nonce] => e2ef1ee7a45c112680d5d835f15dbdf5
[oauth_timestamp] => 1272453429
[oauth_consumer_key] => default
[opensocial_owner_id] => 1
[opensocial_viewer_id] => 1
[opensocial_app_id] => 1
[opensocial_app_url] => http://theappurl/gadget.xml
[oauth_token] =>
[xoauth_signature_publickey] => http://newshindig/public.cer
[xoauth_public_key] => http://newshindig/public.cer
[oauth_signature_method] => RSA-SHA1
[oauth_signature] => averylongstringwithrandomchars
)
oauth_token is empty, is that ok or a problem?
Is any other required data missing?
ヨンニ ベリィストロム wrote:
> Not sure what you mean by the security token - but I've made some
> progress here, it doesn't end with error anymore, and a request is
> successfully (?) sent to the application server.
> I haven't figured out how to sign it successfully there yet.
>
>
> Evgeny Bogdanov wrote:
>> What is the security token, that you use?
>>
>> On 28.04.10 10:24, ヨンニ ベリィストロム wrote:
>>> I'm using the latest (php) Shindig/Partuza from the trunk (well, ~ 1
>>> week old copy).
>>>
>>> I haven't been able to use SIGNED authorization with
>>> gadgets.io.makeRequest.
>>>
>>> Unsigned works well, I'm using the JSON contenttype.
>>>
>>>
>>> With signed, I tried to set up public/private key files like described
>>> in /shindig/certs/README, I get the files and everything + add the pass
>>> phrase into the 'private_key_phrase' in (and local.php), but the server
>>> responds with error 500, "INVALID_GADGET_TOKEN".
>>>
>>> Could someone point me to some setup instructions?
>>>
>>> Thank you
>>>
>>> /Jonny
>>>
Re: Failed secure makeRequest
Posted by ヨンニ ベリィストロム <jo...@unigent.jp>.
Not sure what you mean by the security token - but I've made some
progress here, it doesn't end with error anymore, and a request is
successfully (?) sent to the application server.
I haven't figured out how to sign it successfully there yet.
Evgeny Bogdanov wrote:
> What is the security token, that you use?
>
> On 28.04.10 10:24, ヨンニ ベリィストロム wrote:
>> I'm using the latest (php) Shindig/Partuza from the trunk (well, ~ 1
>> week old copy).
>>
>> I haven't been able to use SIGNED authorization with
>> gadgets.io.makeRequest.
>>
>> Unsigned works well, I'm using the JSON contenttype.
>>
>>
>> With signed, I tried to set up public/private key files like described
>> in /shindig/certs/README, I get the files and everything + add the pass
>> phrase into the 'private_key_phrase' in (and local.php), but the server
>> responds with error 500, "INVALID_GADGET_TOKEN".
>>
>> Could someone point me to some setup instructions?
>>
>> Thank you
>>
>> /Jonny
>>
>
>
Re: Failed secure makeRequest
Posted by Evgeny Bogdanov <ev...@epfl.ch>.
What is the security token, that you use?
On 28.04.10 10:24, ヨンニ ベリィストロム wrote:
> I'm using the latest (php) Shindig/Partuza from the trunk (well, ~ 1
> week old copy).
>
> I haven't been able to use SIGNED authorization with gadgets.io.makeRequest.
>
> Unsigned works well, I'm using the JSON contenttype.
>
>
> With signed, I tried to set up public/private key files like described
> in /shindig/certs/README, I get the files and everything + add the pass
> phrase into the 'private_key_phrase' in (and local.php), but the server
> responds with error 500, "INVALID_GADGET_TOKEN".
>
> Could someone point me to some setup instructions?
>
> Thank you
>
> /Jonny
>
Failed secure makeRequest
Posted by ヨンニ ベリィストロム <jo...@unigent.jp>.
I'm using the latest (php) Shindig/Partuza from the trunk (well, ~ 1
week old copy).
I haven't been able to use SIGNED authorization with gadgets.io.makeRequest.
Unsigned works well, I'm using the JSON contenttype.
With signed, I tried to set up public/private key files like described
in /shindig/certs/README, I get the files and everything + add the pass
phrase into the 'private_key_phrase' in (and local.php), but the server
responds with error 500, "INVALID_GADGET_TOKEN".
Could someone point me to some setup instructions?
Thank you
/Jonny
Re: Rewriting gadgets.js
Posted by Paul Lindner <li...@inuus.com>.
I've put my experimental gadgets.js rewrite code on github at
http://github.com/lindner/shindig/commits/connect
To try it out use:
mvn
mvn -Prun
http://localhost:8080/connect/page.html
Here's what's supported:
* gadget tags
<os:gadget url="xxxx"/></os:gadget>
* context/config tag
<os:config language="de" country="DE"/>
* simple name substitutions in the parent page
<os:Name></os:Name>
* Canvas page implemented as a popover with nice transition effects
* Metadata endpoint that can inject security tokens into iframe URLs. You
will need to provide your own subclass of JsonRpcHandler that implements
getSecurityTokenForRequest() and getViewerForRequest()
* Extension to the views mechanism for 'chromeless' gadgets. These are
gadgets that can be inlined (think buttons!)
* Support for preferredHeight/preferredWidth, gadgets can now come in any
size!
* Supports a simple template mechanism so implementors could override them.
(Will need to move this to gadgets.config to provide full container, by
container customizations however..)
Specific responses inline below:
On Fri, Apr 16, 2010 at 5:20 AM, Tim Wintle <ti...@teamrubber.com> wrot
>
> The method below looks really clean :-) - I haven't had time to think
> through the consequences of the method below enough, but here are a few
> comments off the top of my head:
>
> (a)
> How do you add a new gadget on the client-side after initial render?
>
During page load you can use document.write('<os:gadget...');
After dom load you could potentially invoke the parseDom manually on the
page context. This is how the canvas view is implemented internally.
> Similarly for other changes (position etc). Do you modify the os
> namespaced nodes or do you use the layoutmanager?
>
Iframes and chrome divs are injected directly into the DOM where you see
<os:gadget>
> (b)
> I'm almost exclusively using the gadget server part of shindig - user
> and owner are passed through from the container, but aren't really known
> by shindig - I see the overrides would probably let me do that, but just
> wanted to check.
>
> > Here's an example of where I'm headed:
> >
> > <!-- load up the container JS, include the container=default here...-->
> > <head>
> > <script type="text/javascript"
> >
> src="../../js/rpc:shindig.connect:core.js?container=default&c=1"></script>
> > <os:config view="home" lang="en" country="US"/>
> > </head>
> > <body onLoad="shindig.container.render()">
> > Hello <os:viewer attr="displayName"/> on page owned by <os:owner
> > attr="displayName"/>
> >
> > <os:gadget moduleId="2" url="
> > http://www.google.com/ig/modules/horoscope.xml"></os:gadget>
> > <body>
> >
> >
> > The JsServlet (used in the script tag above) injects ContainerConfig and
> is
> > modified to emit container specific information including the relayUrl,
> > skins info, etc. This is optionally overridden in the os:config tag
> along
> > with per-request info like locale and view.
> >
> > shindig.container.render() gathers the <os:gadget...> entries from the
> DOM,
> > assigns unique IDs and constructs a suitable metadata call using JSONP.
> >
> > The metadata servlet is modified to return security tokens as part of the
> > response, and will return basic viewer/owner information too -- it can do
> > this since it runs on a domain where an existing user has cookie values.
> >
> > The handler for the metadata response then adds the iframes to the DOM,
> > calls gadgets.rpc.setupReceiver() and substitutes values for os:viewer
> and
> > os:owner, and the page is displayed!
> >
> > Thoughts on this as a technique? Anyone interesting in working with me
> on
> > this?
> >
> > One very intriguing possibility is running the metadata servlet on a
> central
> > host and allowing anyone to syndicate the entire system by creating a
> > container for each partner that wants access to the users on that central
> > host.
>
>
Re: Rewriting gadgets.js
Posted by Tim Wintle <ti...@teamrubber.com>.
On Fri, 2010-04-16 at 02:51 -0700, Paul Lindner wrote:
> I've been spending some time making it easier to implement gadgets in a
> container and it seems like I'm going down the path of rewriting
> gadgets.js.
>
> I'd like to hear what others have done with/to this to implement their
> containers and hopefully make something that works much better.
Well, I've basically re-written just most of gadgets.js for my own needs
- I couldn't get my requirements to fit into the current code (at least
mentally), so rewriting the default may well be a good idea (although
I'm worried about migration).
The method below looks really clean :-) - I haven't had time to think
through the consequences of the method below enough, but here are a few
comments off the top of my head:
(a)
How do you add a new gadget on the client-side after initial render?
Similarly for other changes (position etc). Do you modify the os
namespaced nodes or do you use the layoutmanager?
(b)
I'm almost exclusively using the gadget server part of shindig - user
and owner are passed through from the container, but aren't really known
by shindig - I see the overrides would probably let me do that, but just
wanted to check.
> Here's an example of where I'm headed:
>
> <!-- load up the container JS, include the container=default here...-->
> <head>
> <script type="text/javascript"
> src="../../js/rpc:shindig.connect:core.js?container=default&c=1"></script>
> <os:config view="home" lang="en" country="US"/>
> </head>
> <body onLoad="shindig.container.render()">
> Hello <os:viewer attr="displayName"/> on page owned by <os:owner
> attr="displayName"/>
>
> <os:gadget moduleId="2" url="
> http://www.google.com/ig/modules/horoscope.xml"></os:gadget>
> <body>
>
>
> The JsServlet (used in the script tag above) injects ContainerConfig and is
> modified to emit container specific information including the relayUrl,
> skins info, etc. This is optionally overridden in the os:config tag along
> with per-request info like locale and view.
>
> shindig.container.render() gathers the <os:gadget...> entries from the DOM,
> assigns unique IDs and constructs a suitable metadata call using JSONP.
>
> The metadata servlet is modified to return security tokens as part of the
> response, and will return basic viewer/owner information too -- it can do
> this since it runs on a domain where an existing user has cookie values.
>
> The handler for the metadata response then adds the iframes to the DOM,
> calls gadgets.rpc.setupReceiver() and substitutes values for os:viewer and
> os:owner, and the page is displayed!
>
> Thoughts on this as a technique? Anyone interesting in working with me on
> this?
>
> One very intriguing possibility is running the metadata servlet on a central
> host and allowing anyone to syndicate the entire system by creating a
> container for each partner that wants access to the users on that central
> host.
Re: Rewriting gadgets.js
Posted by Paul Lindner <li...@inuus.com>.
Hi Evan,
These are all great ideas. It would be curious to see how this performs,
especially since the metadata request uses JSONP in my prototype. Do you
have existing code that implements what you described?
In any case it would be good to have a new 'apps' handler which could
handle:
- metadata lookups by ID/URL/container (like we have now)
- fetch list of applications known to the container
- with support of filtering/sorting/pagination
- fetch list of applications granted access by existing user.
- fetch list of applications installed by friends, with count of installs.
- "grant"/"revoke" access for apps per user.
This could handle the container/page bootstrap case, plus it would also be
able to handle creating an application directory application that includes:
- A My Apps page
- A My Friends Apps page.
- A Categorized Application browser
- An app search page.
Now I just need a few spare moments to write this up as an opensocial
extension....
On Mon, Apr 19, 2010 at 11:22 AM, Evan Gilbert <ui...@google.com> wrote:
> Yes, we really need APIs to make it easier to create a new container. Few
> notes:
> - Should have a JS API to go along with the declarative syntax for gadgets.
> This makes it possible to render first on the server or client, and then
> re-render using AJAX calls
> - OpenSocial templates is a nice fit for the client implementation. It
> already works on standalone pages with a few config tweaks, and also will
> allow server-side rewriting for performance.
> - Metadata servlet should be written the same way as other APIs (people,
> activities) - this makes it easy to call, batch, etc. With OS data
> pipelining, you can then specifiy the gadget metadata to preload
> (<os:DataRequest method="gadgets.get" uri="
> http://www.google.com/ig/modules/horoscope.xml">)
>
> On Fri, Apr 16, 2010 at 2:51 AM, Paul Lindner <li...@inuus.com> wrote:
>
> > I've been spending some time making it easier to implement gadgets in a
> > container and it seems like I'm going down the path of rewriting
> > gadgets.js.
> >
> > I'd like to hear what others have done with/to this to implement their
> > containers and hopefully make something that works much better.
> >
> > Here's what I've done so far:
> > * Prototyping with jquery
> > * Using custom tags
> > * Using metadata servlet.
> >
> > Here's an example of where I'm headed:
> >
> > <!-- load up the container JS, include the container=default here...-->
> > <head>
> > <script type="text/javascript"
> >
> src="../../js/rpc:shindig.connect:core.js?container=default&c=1"></script>
> > <os:config view="home" lang="en" country="US"/>
> > </head>
> > <body onLoad="shindig.container.render()">
> > Hello <os:viewer attr="displayName"/> on page owned by <os:owner
> > attr="displayName"/>
> >
> > <os:gadget moduleId="2" url="
> > http://www.google.com/ig/modules/horoscope.xml"></os:gadget>
> > <body>
> >
> >
> > The JsServlet (used in the script tag above) injects ContainerConfig and
> is
> > modified to emit container specific information including the relayUrl,
> > skins info, etc. This is optionally overridden in the os:config tag
> along
> > with per-request info like locale and view.
> >
> > shindig.container.render() gathers the <os:gadget...> entries from the
> DOM,
> > assigns unique IDs and constructs a suitable metadata call using JSONP.
> >
> > The metadata servlet is modified to return security tokens as part of the
> > response, and will return basic viewer/owner information too -- it can do
> > this since it runs on a domain where an existing user has cookie values.
> >
> > The handler for the metadata response then adds the iframes to the DOM,
> > calls gadgets.rpc.setupReceiver() and substitutes values for os:viewer
> and
> > os:owner, and the page is displayed!
> >
> > Thoughts on this as a technique? Anyone interesting in working with me
> on
> > this?
> >
> > One very intriguing possibility is running the metadata servlet on a
> > central
> > host and allowing anyone to syndicate the entire system by creating a
> > container for each partner that wants access to the users on that central
> > host.
> >
>
Re: Rewriting gadgets.js
Posted by Evan Gilbert <ui...@google.com>.
Yes, we really need APIs to make it easier to create a new container. Few
notes:
- Should have a JS API to go along with the declarative syntax for gadgets.
This makes it possible to render first on the server or client, and then
re-render using AJAX calls
- OpenSocial templates is a nice fit for the client implementation. It
already works on standalone pages with a few config tweaks, and also will
allow server-side rewriting for performance.
- Metadata servlet should be written the same way as other APIs (people,
activities) - this makes it easy to call, batch, etc. With OS data
pipelining, you can then specifiy the gadget metadata to preload
(<os:DataRequest method="gadgets.get" uri="
http://www.google.com/ig/modules/horoscope.xml">)
On Fri, Apr 16, 2010 at 2:51 AM, Paul Lindner <li...@inuus.com> wrote:
> I've been spending some time making it easier to implement gadgets in a
> container and it seems like I'm going down the path of rewriting
> gadgets.js.
>
> I'd like to hear what others have done with/to this to implement their
> containers and hopefully make something that works much better.
>
> Here's what I've done so far:
> * Prototyping with jquery
> * Using custom tags
> * Using metadata servlet.
>
> Here's an example of where I'm headed:
>
> <!-- load up the container JS, include the container=default here...-->
> <head>
> <script type="text/javascript"
> src="../../js/rpc:shindig.connect:core.js?container=default&c=1"></script>
> <os:config view="home" lang="en" country="US"/>
> </head>
> <body onLoad="shindig.container.render()">
> Hello <os:viewer attr="displayName"/> on page owned by <os:owner
> attr="displayName"/>
>
> <os:gadget moduleId="2" url="
> http://www.google.com/ig/modules/horoscope.xml"></os:gadget>
> <body>
>
>
> The JsServlet (used in the script tag above) injects ContainerConfig and is
> modified to emit container specific information including the relayUrl,
> skins info, etc. This is optionally overridden in the os:config tag along
> with per-request info like locale and view.
>
> shindig.container.render() gathers the <os:gadget...> entries from the DOM,
> assigns unique IDs and constructs a suitable metadata call using JSONP.
>
> The metadata servlet is modified to return security tokens as part of the
> response, and will return basic viewer/owner information too -- it can do
> this since it runs on a domain where an existing user has cookie values.
>
> The handler for the metadata response then adds the iframes to the DOM,
> calls gadgets.rpc.setupReceiver() and substitutes values for os:viewer and
> os:owner, and the page is displayed!
>
> Thoughts on this as a technique? Anyone interesting in working with me on
> this?
>
> One very intriguing possibility is running the metadata servlet on a
> central
> host and allowing anyone to syndicate the entire system by creating a
> container for each partner that wants access to the users on that central
> host.
>