Understanding URL gadgets....

[Mark D Weitzel <we...@us.ibm.com>]

I've got a quick question, which may be more of a confirmation than 
anything else. I also think there's some subtle points or nuances that 
vary between opensocial providers, but hopefully, you'll get the idea of 
what I'm asking. The reason I'm asking is two fold. The first is to make 
sure I understand the roles of the gadget server relative to the client 
when we are working with URL gadgets. The second reason is a 
non-technical, and likely varies based on who is serving up the gadget.

Suppose I've got an internal web site that is running behind a firewall 
that has some private data on it. I'd like my users to be able to see this 
information in a gadget from their landing page, e.g. iGoogle, MySpace, 
et... 

Now, it seems like a very simple and direct way for me to provide this is 
to create a gadget with the content type of URL. When the user hits their 
landing page the server will load my page. When it hits my gadget, it will 
go through Renderer which will create the iFrame and send it to the 
client. When the client gets this and the onLoad is triggered, the gadget 
then makes the http call to my servers. So, for example, if I don't have 
my VPN client loaded, the page would not be able to load. Also, the 
content is never streamed through the server providing the landing page. 
That is, once the gadget is served up, all the communication goes from the 
gadget on the client to my server and does not pass through the server 
that parsed the gadget definition. Is this roughly correct?

Regarding the second reason... In some cases, the TOCs state that when you 
deploy a gadget to the landing page, you grant a license to the content 
that the gadget provides. When you have html gadgets, the content needs to 
go through re-writer, so in this case, the server that provides the 
landing page does process the content of the gadget. However, in URL 
gadgets this does not seem to be the case. So, granted most of us are not 
lawyers, but it would seem in the case of a URL gadget, that since the 
gadget does not serve up the content, there's no license granted. 

Does this make sense or am I off in left field getting heckled by the 
fans?

Thanks!

-Mark W.

RE: Understanding URL gadgets....

["Weygandt, Jon" <jw...@ebay.com>]

Regarding the JavaScript APIs for a URL gadget: We have been able to get almost all the core features working for URL gadgets. The most important ones being dynamic height. makeRequest and dataRequests are limited by the same origin restrictions.
 
Our audience is a bit different than Open Social, applications for e-commerce, but the Gadget Server mechanics are really the same (http://developer.ebay.com/products/selling-manager-applications/). And it turns out that most of the existing developers using our older APIs have extensive applications and using URL gadget they can easily port them to the Gadget APIs, which is great for adoption of the technology.
 
Since it did not seem that Shindig had much support for the "libs" parameters, and iGoogle totally punted on making the gadgets APIs work with URL gadgets, we took a slightly different approach. We placed a single parameter "is" that is signed and contains all the necessary JS to enable the functions. (http://developer.ebay.com/DevZone/selling-manager-applications/Concepts/SellingManagerApps_APIGuide.html#content-types)
 
As to limiting the URL developer to use REST and RPC, well that's simply they way they develop applications, and I don't think that would be a disadvantage, just simply different.
 
Jon

________________________________

From: Kevin Brown [mailto:etnu@google.com]
Sent: Mon 7/6/2009 1:29 PM
To: shindig-dev@incubator.apache.org
Subject: Re: Understanding URL gadgets....



Your assessment is basically correct, though I don't recommend type url
gadgets if you can avoid them. They're not really supported well by the
standard. The javascript APIs won't work at all unless the container has
done a lot of work (and it will probably be slow), so you have to live with
REST/RPC to do anything interesting.

On Mon, Jul 6, 2009 at 12:13 PM, Mark D Weitzel <we...@us.ibm.com> wrote:

> I've got a quick question, which may be more of a confirmation than
> anything else. I also think there's some subtle points or nuances that
> vary between opensocial providers, but hopefully, you'll get the idea of
> what I'm asking. The reason I'm asking is two fold. The first is to make
> sure I understand the roles of the gadget server relative to the client
> when we are working with URL gadgets. The second reason is a
> non-technical, and likely varies based on who is serving up the gadget.
>
> Suppose I've got an internal web site that is running behind a firewall
> that has some private data on it. I'd like my users to be able to see this
> information in a gadget from their landing page, e.g. iGoogle, MySpace,
> et...
>
> Now, it seems like a very simple and direct way for me to provide this is
> to create a gadget with the content type of URL. When the user hits their
> landing page the server will load my page. When it hits my gadget, it will
> go through Renderer which will create the iFrame and send it to the
> client. When the client gets this and the onLoad is triggered, the gadget
> then makes the http call to my servers. So, for example, if I don't have
> my VPN client loaded, the page would not be able to load. Also, the
> content is never streamed through the server providing the landing page.
> That is, once the gadget is served up, all the communication goes from the
> gadget on the client to my server and does not pass through the server
> that parsed the gadget definition. Is this roughly correct?
>
> Regarding the second reason... In some cases, the TOCs state that when you
> deploy a gadget to the landing page, you grant a license to the content
> that the gadget provides. When you have html gadgets, the content needs to
> go through re-writer, so in this case, the server that provides the
> landing page does process the content of the gadget. However, in URL
> gadgets this does not seem to be the case. So, granted most of us are not
> lawyers, but it would seem in the case of a URL gadget, that since the
> gadget does not serve up the content, there's no license granted.
>
> Does this make sense or am I off in left field getting heckled by the
> fans?
>
> Thanks!
>
> -Mark W.
>
>
>
>
>
>

Re: Understanding URL gadgets....

[Kevin Brown <et...@google.com>]

Your assessment is basically correct, though I don't recommend type url
gadgets if you can avoid them. They're not really supported well by the
standard. The javascript APIs won't work at all unless the container has
done a lot of work (and it will probably be slow), so you have to live with
REST/RPC to do anything interesting.

On Mon, Jul 6, 2009 at 12:13 PM, Mark D Weitzel <we...@us.ibm.com> wrote:

> I've got a quick question, which may be more of a confirmation than
> anything else. I also think there's some subtle points or nuances that
> vary between opensocial providers, but hopefully, you'll get the idea of
> what I'm asking. The reason I'm asking is two fold. The first is to make
> sure I understand the roles of the gadget server relative to the client
> when we are working with URL gadgets. The second reason is a
> non-technical, and likely varies based on who is serving up the gadget.
>
> Suppose I've got an internal web site that is running behind a firewall
> that has some private data on it. I'd like my users to be able to see this
> information in a gadget from their landing page, e.g. iGoogle, MySpace,
> et...
>
> Now, it seems like a very simple and direct way for me to provide this is
> to create a gadget with the content type of URL. When the user hits their
> landing page the server will load my page. When it hits my gadget, it will
> go through Renderer which will create the iFrame and send it to the
> client. When the client gets this and the onLoad is triggered, the gadget
> then makes the http call to my servers. So, for example, if I don't have
> my VPN client loaded, the page would not be able to load. Also, the
> content is never streamed through the server providing the landing page.
> That is, once the gadget is served up, all the communication goes from the
> gadget on the client to my server and does not pass through the server
> that parsed the gadget definition. Is this roughly correct?
>
> Regarding the second reason... In some cases, the TOCs state that when you
> deploy a gadget to the landing page, you grant a license to the content
> that the gadget provides. When you have html gadgets, the content needs to
> go through re-writer, so in this case, the server that provides the
> landing page does process the content of the gadget. However, in URL
> gadgets this does not seem to be the case. So, granted most of us are not
> lawyers, but it would seem in the case of a URL gadget, that since the
> gadget does not serve up the content, there's no license granted.
>
> Does this make sense or am I off in left field getting heckled by the
> fans?
>
> Thanks!
>
> -Mark W.
>
>
>
>
>
>

Re: Understanding URL gadgets....

[Gabriel Barros <gb...@yahoo-inc.com>]

Le lundi 06 juillet 2009 à 15:13 -0400, Mark D Weitzel a écrit :
> I've got a quick question, which may be more of a confirmation than 
> anything else. I also think there's some subtle points or nuances that 
> vary between opensocial providers, but hopefully, you'll get the idea of 
> what I'm asking. The reason I'm asking is two fold. The first is to make 
> sure I understand the roles of the gadget server relative to the client 
> when we are working with URL gadgets. The second reason is a 
> non-technical, and likely varies based on who is serving up the gadget.
> 
> Suppose I've got an internal web site that is running behind a firewall 
> that has some private data on it. I'd like my users to be able to see this 
> information in a gadget from their landing page, e.g. iGoogle, MySpace, 
> et... 

You can make the presentation and logic regularly (i.e. type=html), and
use YUI's Get[1] to fetch the data from your internal network.

[1] "Using the Get Utility to Insert Script Nodes"
http://developer.yahoo.com/yui/get/#script


> Now, it seems like a very simple and direct way for me to provide this is 
> to create a gadget with the content type of URL. When the user hits their 
> landing page the server will load my page. When it hits my gadget, it will 
> go through Renderer which will create the iFrame and send it to the 
> client. When the client gets this and the onLoad is triggered, the gadget 
> then makes the http call to my servers. So, for example, if I don't have 
> my VPN client loaded, the page would not be able to load. Also, the 
> content is never streamed through the server providing the landing page. 
> That is, once the gadget is served up, all the communication goes from the 
> gadget on the client to my server and does not pass through the server 
> that parsed the gadget definition. Is this roughly correct?
> 
> Regarding the second reason... In some cases, the TOCs state that when you 
> deploy a gadget to the landing page, you grant a license to the content 
> that the gadget provides. When you have html gadgets, the content needs to 
> go through re-writer, so in this case, the server that provides the 
> landing page does process the content of the gadget. However, in URL 
> gadgets this does not seem to be the case. So, granted most of us are not 
> lawyers, but it would seem in the case of a URL gadget, that since the 
> gadget does not serve up the content, there's no license granted. 

IANAL, but If it's in an internal network, then no need to fear this.
Also, I bet they put it there just to prevent *you* from suing them for
their content caching. In the end, ask an lawyer (they go great lengths
to make you need them, so show some feelings and do your part. the poor
things).

--gbarros