Forgot to put link for the performance claim:
http://developer.yahoo.com/performance/rules.html#external
- Henry
On Wed, Jul 13, 2011 at 7:03 PM, Henry Saputra wrote:
> One advantage is that the javascript could be cached so different
> gadgets having the same features should not require request
Ok, I was wrong, the RenderingGadgetRewriter DOES call
JsServingPipeline to run the processor.
- Henry
On Wed, Jul 13, 2011 at 7:03 PM, Henry Saputra wrote:
> One advantage is that the javascript could be cached so different
> gadgets having the same features should not require request to server
One advantage is that the javascript could be cached so different
gadgets having the same features should not require request to server
to get it again.
Second, Fargo or Michael could correct me on this, the JS serving path
via JsServlet allow JS compiler via closure and JS processor flow to
proce
Ryan,
Thanks for responding. Was starting to wonder if my messages were making it to
the mail list.
Yes I'm using appdata for a userpref store. Regardless of whether that is the
right
approach or not, the rpc call still seems like it should be using the gadget
security token
instead of the con
So what's the benefit of doing this? Just trying to understand why this
would be better.
-Ryan
Email: rjbax...@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra
To: dev@shindig.apache.org,
Date: 07/12/2011 11:11 PM
Subject:Re: Setting
shindig.gadget
Doug just try to understand your situation, are using app data as a way
to store preferences? So your registering an RPC handler for set pref in
your container and your container is calling osapi.appdata.update(...)?
-Ryan
Email: rjbax...@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1104/
---
(Updated 2011-07-13 21:24:07.030107)
Review request for shindig.
Changes
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1104/#review1048
---
Ship it!
/trunk/content/samplecontainer/examples/commoncontainer/ass
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1104/
---
Review request for shindig.
Summary
---
This was inadvertently removed in a
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1101/#review1046
---
Ship it!
LGTM
- Paul
On 2011-07-13 20:47:28, Matt Marum wrote:
>
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1101/
---
(Updated 2011-07-13 20:47:28.325492)
Review request for shindig.
Summary
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1101/
---
Review request for shindig.
Summary
---
The current implementation of Anony
I put logging in my gadget and printed out the value of
shindig.auth.getSecurityToken and it was the correct one from the iframe
st param. I then log the same value before the osapi.appdata call and
it's the container value. So obviously they are using different
instances of the shindig.auth obje
Shindig 2.0.0 needs to be deployed on the root context for it to work
properly.
Deploy it on the root context then try...
http://localhost:8080/samplecontainer/samplecontainer.html
Matt Marum
|>
| From: |
|>
>
Do you have an oauth key error in your catalina.out? We hit that today too.
We ended up patching the war but it looks like doing a maven build off
the source distro is probably a better approach.
-Mat
On Jul 13, 2011, at 11:25 AM, Guido Zockoll wrote:
> I have downloaded the shindig-2.0.0.war
I have downloaded the shindig-2.0.0.war file an deployed it to an
Tomcat 6.0.x and Tomcat 7.0.x. The manager application shows that it
has been deploy successful and the path is /shindig-server-2.0.0
When trying to access http://localhost:8080/shindig-server-2.0.0 or as
in the docu http://localhos
(Piggy backing on my own thread - and I meant calling appdata, not
userprefs)
I just had a lightbulb go off (I think). Since each gadget is in it's
own iframe I'm thinking that each gadget has it's own shindig.auth
reference. Thus, the security token is per gadget, right? But the
gadget writ
jsonrpctransport.js is using shindig.auth.getSecurityToken(). This is
great if the json rpc request is coming from the container. However,
not if it's coming from the gadget. For example let's say my gadget is
calling userprefs
osapi.appdata.update({
userid : '@me',
18 matches
Mail list logo
