Realizing that this may be a sensitive topic, I want to give everyone *advanced* notice that inlined gadgets (type="html-inline") will soon be deprecated from the Gadgets API.
This is an important announcement which I hope will reach as many developers as possible. For authors of existing inlined gadgets, you needn't worry. Your gadgets will continue working as normal. There are some subtleties around what this exactly means, and I'll try to explain them below. I don't have an ETA on when this will happen, but please expect for it to happen soon. The main goal is to give you all a heads up about this change. Feel free to post questions, and I'll do my best to answer them.
====
What does this mean? The deprecation of inlined gadgets means that new inlined gadgets can no longer be created after we turn on the switch. For inlined gadgets that already exist, they will continue to be supported and render as normal. This will just prevent any new inlined gadgets from being created. I can't announce exactly when we'll start the deprecation, but the earlier you start, the better the chances you'll make it in time.
Why? Inlined gadgets pose potential security risks to our users in addition to other complications with some API libraries, e.g. Analytics. They're more difficult to develop and cannot be syndicated via Google Gadgets For Your Webpage. This is one of the major reasons why inlined gadgets are generally less discoverable and don't get as much traffic as type="html" gadgets. Supporting inlined gadgets can be difficult because many inlined gadgets depend on specific DOM elements in the iGoogle container page. The container page can frequently change and essentially break your gadget. Just ask Bonstio and Matt ;). By deprecating inlined gadgets, it allows us to standardize the way gadgets are rendered and create a more consistent API resulting in a better developer experience.
Will inlined gadgets be closed forever? Initially, we will not be honoring requests to add additional inlined gadgets. In the future, we may consider allowing developers to submit a proposal to develop an inlined gadget and have it go through an approvals process. However, please understand that this is purely hypothetical at this point with no ETA. The current plan is that once we deprecate inlining, we will stop allowing new inlined gadgets, without exceptions.
Feedback? This announcement is intended to give advanced notice of this upcoming change. Feel free to post comments/questions, and I'll do my best to answer them.
I can totally understand the need to do this and I must say it's not a total surprise either. Standardizing is good and I can surely see the disadvantages in terms of brittleness and security.
I would have been extremely bitter about many lost hours of development - and users - were it not for the fact that you will continue to support existing inlined gadgets so I'm very pleased that you've collectively decided to do this - nice one, thanks! And thanks for the up-front notice too :)
My question is this: on what basis will existing inline gadgets continue to be supported? Uniquely selected by their URL or name? A manual developer initiated request? Some of my gadgets live at two different URLs. I suppose I could submit an alias request to overcome this. I'd just be interested to know how you are going to work this.
CHEERS,
-Greg
On Nov 8, 6:03 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> Realizing that this may be a sensitive topic, I want to give everyone > *advanced* notice that inlined gadgets (type="html-inline") will soon > be deprecated from the Gadgets API.
> This is an important announcement which I hope will reach as many > developers as possible. For authors of existing inlined gadgets, you > needn't worry. Your gadgets will continue working as normal. There > are some subtleties around what this exactly means, and I'll try to > explain them below. I don't have an ETA on when this will happen, but > please expect for it to happen soon. The main goal is to give you all > a heads up about this change. Feel free to post questions, and I'll > do my best to answer them.
> ====
> What does this mean? > The deprecation of inlined gadgets means that new inlined gadgets can > no longer be created after we turn on the switch. For inlined gadgets > that already exist, they will continue to be supported and render as > normal. This will just prevent any new inlined gadgets from being > created. I can't announce exactly when we'll start the deprecation, > but the earlier you start, the better the chances you'll make it in > time.
> Why? > Inlined gadgets pose potential security risks to our users in addition > to other complications with some API libraries, e.g. Analytics. > They're more difficult to develop and cannot be syndicated via Google > Gadgets For Your Webpage. This is one of the major reasons why > inlined gadgets are generally less discoverable and don't get as much > traffic as type="html" gadgets. Supporting inlined gadgets can be > difficult because many inlined gadgets depend on specific DOM elements > in the iGoogle container page. The container page can frequently > change and essentially break your gadget. Just ask Bonstio and > Matt ;). By deprecating inlined gadgets, it allows us to standardize > the way gadgets are rendered and create a more consistent API > resulting in a better developer experience.
> Will inlined gadgets be closed forever? > Initially, we will not be honoring requests to add additional inlined > gadgets. In the future, we may consider allowing developers to submit > a proposal to develop an inlined gadget and have it go through an > approvals process. However, please understand that this is purely > hypothetical at this point with no ETA. The current plan is that once > we deprecate inlining, we will stop allowing new inlined gadgets, > without exceptions.
> Feedback? > This announcement is intended to give advanced notice of this upcoming > change. Feel free to post comments/questions, and I'll do my best to > answer them.
On Nov 8, 12:03 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> Realizing that this may be a sensitive topic, I want to give everyone > *advanced* notice that inlined gadgets (type="html-inline") will soon > be deprecated from the Gadgets API.
Thank you for the notice, but I must say that I'm very disappointed.
Many of the gadgets I develop are for my own use - I don't even care if anyone else uses them. I find it very handy to use inlined gadgets because I can do more with them and I don't have to deal with the issues of iframes, resizing, etc. Inline gadgets just work better, IMO. Even if they aren't popular, what's the harm in allowing them to continue to be created? If users don't mind the security "risks" why reduce their choice? You're effectively turning of all access to skinning the igoogle page, correct?
I'm glad that existing gadgets will continue to be supported, at least. Otherwise I would probably abandon iGoogle immediately, as I would need to re-write every gadget I have on my home page! I have three questions: 1) Can I update the XML of an inlined gadget that already exists, once you have flipped the switch? 2) If so, can I add, say, 10 inlined gadgets right now as "placeholders" and then modify the XML in the future to create a different gadget? 3) Will inlined gadgets only continue to work if they exist in the directory? Or if I've added them by url, will they continue to work?
I've looked into the mechanism that allows iframe gadgets to communicate with the main page, to resize themselves, etc. It seems very closed off and limited to only the messages that you support. Would you consider opening that up a bit more and allowing iframe gadgets to do more things to their containing page? That would at least allow for skinning, gadgets with icons in their header bars, etc. If I couldn't use my skin gadget, iGoogle would be much less usable to me because of real estate issues, colors, etc.
I'm disappointed in the change, but oh well. I guess I'll have to look into converting some of my gadgets into non-inlined form...
I can understand why you feel this way for sure. Good point if these gadgets are purely for your own use too. Also a good question about the ability to update an inlined gadget.
On Nov 8, 8:50 pm, "Matt (Guru)" <m...@mattkruse.com> wrote:
> On Nov 8, 12:03 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> > Realizing that this may be a sensitive topic, I want to give everyone > > *advanced* notice that inlined gadgets (type="html-inline") will soon > > be deprecated from the Gadgets API.
> Thank you for the notice, but I must say that I'm very disappointed.
> Many of the gadgets I develop are for my own use - I don't even care > if anyone else uses them. I find it very handy to use inlined gadgets > because I can do more with them and I don't have to deal with the > issues of iframes, resizing, etc. Inline gadgets just work better, > IMO. Even if they aren't popular, what's the harm in allowing them to > continue to be created? If users don't mind the security "risks" why > reduce their choice? You're effectively turning of all access to > skinning the igoogle page, correct?
> I'm glad that existing gadgets will continue to be supported, at > least. Otherwise I would probably abandon iGoogle immediately, as I > would need to re-write every gadget I have on my home page! I have > three questions: > 1) Can I update the XML of an inlined gadget that already exists, once > you have flipped the switch? > 2) If so, can I add, say, 10 inlined gadgets right now as > "placeholders" and then modify the XML in the future to create a > different gadget? > 3) Will inlined gadgets only continue to work if they exist in the > directory? Or if I've added them by url, will they continue to work?
> I've looked into the mechanism that allows iframe gadgets to > communicate with the main page, to resize themselves, etc. It seems > very closed off and limited to only the messages that you support. > Would you consider opening that up a bit more and allowing iframe > gadgets to do more things to their containing page? That would at > least allow for skinning, gadgets with icons in their header bars, > etc. If I couldn't use my skin gadget, iGoogle would be much less > usable to me because of real estate issues, colors, etc.
> I'm disappointed in the change, but oh well. I guess I'll have to look > into converting some of my gadgets into non-inlined form...
As always, thanks for the feedback. Answers to your questions below:
> My question is this: on what basis will existing inline gadgets continue to be supported? > Uniquely selected by their URL or name?
We will continue supporting existing inlined gadgets based on their URL. If at some point, one of your inlined gadgets has moved and needs to be aliased to a new location, this is not a problem, and I'll be happy to satisfy this request for you. This also means that you can freely update your existing inlined gadget as you normally would without any restriction.
Hope that helps,
Dann
On Nov 8, 10:49 am, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> I can totally understand the need to do this and I must say it's not a > total surprise either. Standardizing is good and I can surely see the > disadvantages in terms of brittleness and security.
> I would have been extremely bitter about many lost hours of > development - and users - were it not for the fact that you will > continue to support existing inlined gadgets so I'm very pleased that > you've collectively decided to do this - nice one, thanks! And thanks > for the up-front notice too :)
> My question is this: on what basis will existing inline gadgets > continue to be supported? Uniquely selected by their URL or name? A > manual developer initiated request? Some of my gadgets live at two > different URLs. I suppose I could submit an alias request to overcome > this. I'd just be interested to know how you are going to work this.
> CHEERS,
> -Greg
> On Nov 8, 6:03 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> > Hey everyone,
> > Realizing that this may be a sensitive topic, I want to give everyone > > *advanced* notice that inlined gadgets (type="html-inline") will soon > > be deprecated from the Gadgets API.
> > This is an important announcement which I hope will reach as many > > developers as possible. For authors of existing inlined gadgets, you > > needn't worry. Your gadgets will continue working as normal. There > > are some subtleties around what this exactly means, and I'll try to > > explain them below. I don't have an ETA on when this will happen, but > > please expect for it to happen soon. The main goal is to give you all > > a heads up about this change. Feel free to post questions, and I'll > > do my best to answer them.
> > ====
> > What does this mean? > > The deprecation of inlined gadgets means that new inlined gadgets can > > no longer be created after we turn on the switch. For inlined gadgets > > that already exist, they will continue to be supported and render as > > normal. This will just prevent any new inlined gadgets from being > > created. I can't announce exactly when we'll start the deprecation, > > but the earlier you start, the better the chances you'll make it in > > time.
> > Why? > > Inlined gadgets pose potential security risks to our users in addition > > to other complications with some API libraries, e.g. Analytics. > > They're more difficult to develop and cannot be syndicated via Google > > Gadgets For Your Webpage. This is one of the major reasons why > > inlined gadgets are generally less discoverable and don't get as much > > traffic as type="html" gadgets. Supporting inlined gadgets can be > > difficult because many inlined gadgets depend on specific DOM elements > > in the iGoogle container page. The container page can frequently > > change and essentially break your gadget. Just ask Bonstio and > > Matt ;). By deprecating inlined gadgets, it allows us to standardize > > the way gadgets are rendered and create a more consistent API > > resulting in a better developer experience.
> > Will inlined gadgets be closed forever? > > Initially, we will not be honoring requests to add additional inlined > > gadgets. In the future, we may consider allowing developers to submit > > a proposal to develop an inlined gadget and have it go through an > > approvals process. However, please understand that this is purely > > hypothetical at this point with no ETA. The current plan is that once > > we deprecate inlining, we will stop allowing new inlined gadgets, > > without exceptions.
> > Feedback? > > This announcement is intended to give advanced notice of this upcoming > > change. Feel free to post comments/questions, and I'll do my best to > > answer them.
> Many of the gadgets I develop are for my own use - I don't even care > if anyone else uses them. I find it very handy to use inlined gadgets > because I can do more with them and I don't have to deal with the > issues of iframes, resizing, etc. Inline gadgets just work better, > IMO. Even if they aren't popular, what's the harm in allowing them to > continue to be created? If users don't mind the security "risks" why > reduce their choice? You're effectively turning of all access to > skinning the igoogle page, correct?
You do bring up an interesting point. You may be right that some users don't mind the security risks, but part of our job is to pro- actively protect our users from potential attacks. It wasn't an easy decision to make, but the fact is that inlined gadgets has always compromised security in various ways. The truth is that many users do get scared away from the opt-in message that gets displayed when adding a third-party inlined gadget. So I do think we need to keep this in mind.
In addition to security, there are other complications and limitations surrounding inlined gadgets such as the inability to add them to other pages, etc. However, this is probably irrelevant to someone who really wants to use inlined gadgets for their own personal use.
> 1) Can I update the XML of an inlined gadget that already exists, once > you have flipped the switch?
Yes. After the switch is flipped, you can continue to update inlined gadget as you normally would.
> 2) If so, can I add, say, 10 inlined gadgets right now as > "placeholders" and then modify the XML in the future to create a > different gadget?
Possibly, which is part of the reason why I posted the announcement in advance. However, I can't guarantee that they'll make it in since they'll probably have very low traffic. I'd go ahead and create them anyway as you might as well try.
> 3) Will inlined gadgets only continue to work if they exist in the > directory? Or if I've added them by url, will they continue to work?
Inlined gadgets do not have to exist in the directory to be qualified although you should make sure they are getting some volume of traffic.
> Would you consider opening that up a bit more and allowing iframe > gadgets to do more things to their containing page? That would at > least allow for skinning, gadgets with icons in their header bars, > etc. If I couldn't use my skin gadget, iGoogle would be much less > usable to me because of real estate issues, colors, etc.
Yes, technically this would be possible and may help with the transition. However I don't have any updates on whether this will be available in the near future. These are container-specific features that only apply to iGoogle. So there's naturally going to be some debate over how useful this would be to the general public.
I read in this group that inlined gadget were not supported in GAFYD. I wish they were :-/ The message says "Sorry, this module cannot be displayed, as it requires inlining but is provided by an untrusted source." I would just like to be able to add my gadget URL to the list of trusted sources.
I think that a domain admin for GAFYD takes over from Google's responsibility to proactively proetect users from potential attacks. If the GAFYD admin user deems a gadget as safe, then that's their decision and they should be able to pre-add whichever (currently existing) inlined gadget are required. This is not the same as allowing non-admin GAFYD from adding inlined gadgets.
I'm exploring this as I've recently been inundated with gadget requests for GAFYD and have just remembered from re-reading posts in this group that I will be unable to help out. Is there any possibility of this being changed before the switch is flipped please?
On Nov 9, 11:17 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> Thanks for the valuable feedback. Comments below:
> > Many of the gadgets I develop are for my own use - I don't even care > > if anyone else uses them. I find it very handy to use inlined gadgets > > because I can do more with them and I don't have to deal with the > > issues of iframes, resizing, etc. Inline gadgets just work better, > > IMO. Even if they aren't popular, what's the harm in allowing them to > > continue to be created? If users don't mind the security "risks" why > > reduce their choice? You're effectively turning of all access to > > skinning the igoogle page, correct?
> You do bring up an interesting point. You may be right that some > users don't mind the security risks, but part of our job is to pro- > actively protect our users from potential attacks. It wasn't an easy > decision to make, but the fact is that inlined gadgets has always > compromised security in various ways. The truth is that many users do > get scared away from the opt-in message that gets displayed when > adding a third-party inlined gadget. So I do think we need to keep > this in mind.
> In addition to security, there are other complications and limitations > surrounding inlined gadgets such as the inability to add them to other > pages, etc. However, this is probably irrelevant to someone who > really wants to use inlined gadgets for their own personal use.
> > 1) Can I update the XML of an inlined gadget that already exists, once > > you have flipped the switch?
> Yes. After the switch is flipped, you can continue to update inlined > gadget as you normally would.
> > 2) If so, can I add, say, 10 inlined gadgets right now as > > "placeholders" and then modify the XML in the future to create a > > different gadget?
> Possibly, which is part of the reason why I posted the announcement in > advance. However, I can't guarantee that they'll make it in since > they'll probably have very low traffic. I'd go ahead and create them > anyway as you might as well try.
> > 3) Will inlined gadgets only continue to work if they exist in the > > directory? Or if I've added them by url, will they continue to work?
> Inlined gadgets do not have to exist in the directory to be qualified > although you should make sure they are getting some volume of traffic.
> > Would you consider opening that up a bit more and allowing iframe > > gadgets to do more things to their containing page? That would at > > least allow for skinning, gadgets with icons in their header bars, > > etc. If I couldn't use my skin gadget, iGoogle would be much less > > usable to me because of real estate issues, colors, etc.
> Yes, technically this would be possible and may help with the > transition. However I don't have any updates on whether this will be > available in the near future. These are container-specific features > that only apply to iGoogle. So there's naturally going to be some > debate over how useful this would be to the general public.
I have another observation on this subject... many of my inlined
gadget also have another version which I use for development purposes
before copying the content to the live version. Of course the dev
versions of these gadgets don't get much traffic as only I use them
for development. When inlined gadgets become depricated, will I no
longer be able to have these dev versions? Thanks!
On Nov 10, 10:51 am, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> I read in this group that inlined gadget were not supported in GAFYD.
> I wish they were :-/ The message says "Sorry, this module cannot be
> displayed, as it requires inlining but is provided by an untrusted
> source." I would just like to be able to add my gadget URL to the list
> of trusted sources.
> I think that a domain admin for GAFYD takes over from Google's
> responsibility to proactively proetect users from potential attacks.
> If the GAFYD admin user deems a gadget as safe, then that's their
> decision and they should be able to pre-add whichever (currently
> existing) inlined gadget are required. This is not the same as
> allowing non-admin GAFYD from adding inlined gadgets.
> I'm exploring this as I've recently been inundated with gadget
> requests for GAFYD and have just remembered from re-reading posts in
> this group that I will be unable to help out. Is there any possibility
> of this being changed before the switch is flipped please?
> On Nov 9, 11:17 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> > Hey Matt,
> > Thanks for the valuable feedback. Comments below:
> > > Many of the gadgets I develop are for my own use - I don't even care
> > > if anyone else uses them. I find it very handy to use inlined gadgets
> > > because I can do more with them and I don't have to deal with the
> > > issues of iframes, resizing, etc. Inline gadgets just work better,
> > > IMO. Even if they aren't popular, what's the harm in allowing them to
> > > continue to be created? If users don't mind the security "risks" why
> > > reduce their choice? You're effectively turning of all access to
> > > skinning the igoogle page, correct?
> > You do bring up an interesting point. You may be right that some
> > users don't mind the security risks, but part of our job is to pro-
> > actively protect our users from potential attacks. It wasn't an easy
> > decision to make, but the fact is that inlined gadgets has always
> > compromised security in various ways. The truth is that many users do
> > get scared away from the opt-in message that gets displayed when
> > adding a third-party inlined gadget. So I do think we need to keep
> > this in mind.
> > In addition to security, there are other complications and limitations
> > surrounding inlined gadgets such as the inability to add them to other
> > pages, etc. However, this is probably irrelevant to someone who
> > really wants to use inlined gadgets for their own personal use.
> > > 1) Can I update the XML of an inlined gadget that already exists, once
> > > you have flipped the switch?
> > Yes. After the switch is flipped, you can continue to update inlined
> > gadget as you normally would.
> > > 2) If so, can I add, say, 10 inlined gadgets right now as
> > > "placeholders" and then modify the XML in the future to create a
> > > different gadget?
> > Possibly, which is part of the reason why I posted the announcement in
> > advance. However, I can't guarantee that they'll make it in since
> > they'll probably have very low traffic. I'd go ahead and create them
> > anyway as you might as well try.
> > > 3) Will inlined gadgets only continue to work if they exist in the
> > > directory? Or if I've added them by url, will they continue to work?
> > Inlined gadgets do not have to exist in the directory to be qualified
> > although you should make sure they are getting some volume of traffic.
> > > Would you consider opening that up a bit more and allowing iframe
> > > gadgets to do more things to their containing page? That would at
> > > least allow for skinning, gadgets with icons in their header bars,
> > > etc. If I couldn't use my skin gadget, iGoogle would be much less
> > > usable to me because of real estate issues, colors, etc.
> > Yes, technically this would be possible and may help with the
> > transition. However I don't have any updates on whether this will be
> > available in the near future. These are container-specific features
> > that only apply to iGoogle. So there's naturally going to be some
> > debate over how useful this would be to the general public.
Most of my gadget can be tested in my own mocked up environment, but I
would definitely need the ability to have a testing gadget working off
a second URL. Maybe we could register a testing URL for an existing
inline gadget, which was also continue to work after the switch.
On Nov 15, 6:57 pm, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> I have another observation on this subject... many of my inlined
> gadget also have another version which I use for development purposes
> before copying the content to the live version. Of course the dev
> versions of these gadgets don't get much traffic as only I use them
> for development. When inlined gadgets become depricated, will I no
> longer be able to have these dev versions? Thanks!
> On Nov 10, 10:51 am, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> > I read in this group that inlined gadget were not supported in GAFYD.
> > I wish they were :-/ The message says "Sorry, this module cannot be
> > displayed, as it requires inlining but is provided by an untrusted
> > source." I would just like to be able to add my gadget URL to the list
> > of trusted sources.
> > I think that a domain admin for GAFYD takes over from Google's
> > responsibility to proactively proetect users from potential attacks.
> > If the GAFYD admin user deems a gadget as safe, then that's their
> > decision and they should be able to pre-add whichever (currently
> > existing) inlined gadget are required. This is not the same as
> > allowing non-admin GAFYD from adding inlined gadgets.
> > I'm exploring this as I've recently been inundated with gadget
> > requests for GAFYD and have just remembered from re-reading posts in
> > this group that I will be unable to help out. Is there any possibility
> > of this being changed before the switch is flipped please?
> > On Nov 9, 11:17 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> > > Hey Matt,
> > > Thanks for the valuable feedback. Comments below:
> > > > Many of the gadgets I develop are for my own use - I don't even care
> > > > if anyone else uses them. I find it very handy to use inlined gadgets
> > > > because I can do more with them and I don't have to deal with the
> > > > issues of iframes, resizing, etc. Inline gadgets just work better,
> > > > IMO. Even if they aren't popular, what's the harm in allowing them to
> > > > continue to be created? If users don't mind the security "risks" why
> > > > reduce their choice? You're effectively turning of all access to
> > > > skinning the igoogle page, correct?
> > > You do bring up an interesting point. You may be right that some
> > > users don't mind the security risks, but part of our job is to pro-
> > > actively protect our users from potential attacks. It wasn't an easy
> > > decision to make, but the fact is that inlined gadgets has always
> > > compromised security in various ways. The truth is that many users do
> > > get scared away from the opt-in message that gets displayed when
> > > adding a third-party inlined gadget. So I do think we need to keep
> > > this in mind.
> > > In addition to security, there are other complications and limitations
> > > surrounding inlined gadgets such as the inability to add them to other
> > > pages, etc. However, this is probably irrelevant to someone who
> > > really wants to use inlined gadgets for their own personal use.
> > > > 1) Can I update the XML of an inlined gadget that already exists, once
> > > > you have flipped the switch?
> > > Yes. After the switch is flipped, you can continue to update inlined
> > > gadget as you normally would.
> > > > 2) If so, can I add, say, 10 inlined gadgets right now as
> > > > "placeholders" and then modify the XML in the future to create a
> > > > different gadget?
> > > Possibly, which is part of the reason why I posted the announcement in
> > > advance. However, I can't guarantee that they'll make it in since
> > > they'll probably have very low traffic. I'd go ahead and create them
> > > anyway as you might as well try.
> > > > 3) Will inlined gadgets only continue to work if they exist in the
> > > > directory? Or if I've added them by url, will they continue to work?
> > > Inlined gadgets do not have to exist in the directory to be qualified
> > > although you should make sure they are getting some volume of traffic.
> > > > Would you consider opening that up a bit more and allowing iframe
> > > > gadgets to do more things to their containing page? That would at
> > > > least allow for skinning, gadgets with icons in their header bars,
> > > > etc. If I couldn't use my skin gadget, iGoogle would be much less
> > > > usable to me because of real estate issues, colors, etc.
> > > Yes, technically this would be possible and may help with the
> > > transition. However I don't have any updates on whether this will be
> > > available in the near future. These are container-specific features
> > > that only apply to iGoogle. So there's naturally going to be some
> > > debate over how useful this would be to the general public.
On Nov 16, 9:59 am, Simon <qila...@gmail.com> wrote:
> Most of my gadget can be tested in my own mocked up environment, but I
> would definitely need the ability to have a testing gadget working off
> a second URL. Maybe we could register a testing URL for an existing
> inline gadget, which was also continue to work after the switch.
Wasn't it said that a gadget does not need to be in the directory in
order to continue working? So as long as you have your dev gadget on a
tab, I assume it would be "registered" and continue to work after the
switch-over.
Yes, that's true but there does seem to be a grey area when it comes
to gadgets, such as dev version gadgets, which will receive minimal
volumes of traffic. However, since my last post I have received
official assurance that this shouldn't be a problem and will be
managable by email so this has allayed my fears in this area.
Also I'd like to get others' thoughts on inlined gadgets and GAFYD.
Maybe my long rambling post above is not so clear but what I'm getting
at is the idea that GAFYD administrators should be permitted to
authorize certain inline gadgets for their users. There should still
be restrictions online inlined gadgets for users but they should be
allowed to use inlined gadgets which have been authorized by the GAFYD
administrator. Is this a good / bad idea and moreover, is this an
actual possibility or am I clutching at straws?
On Nov 16, 4:50 pm, "Matt (Guru)" <m...@mattkruse.com> wrote:
> On Nov 16, 9:59 am, Simon <qila...@gmail.com> wrote:
> > Most of my gadget can be tested in my own mocked up environment, but I
> > would definitely need the ability to have a testing gadget working off
> > a second URL. Maybe we could register a testing URL for an existing
> > inline gadget, which was also continue to work after the switch.
> Wasn't it said that a gadget does not need to be in the directory in
> order to continue working? So as long as you have your dev gadget on a
> tab, I assume it would be "registered" and continue to work after the
> switch-over.
I hear your point, but I do think this is somewhat of a separate
discussion. GAFYD has never supported inlined gadgets, and I'm sure
there's reasons why the GAFYD team decided not to enable them. I'd
recommend posting these concerns in the GAFYD discussion group as I
imagine you'll find more answers there. The question of enabling
inlined gadgets in other Google properties is more dependent on that
specific property as opposed to gadgets as a whole. So unfortunately,
I won't be able to help with this.
Sorry!
Dann
On Nov 10, 2:51 am, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> I read in this group that inlined gadget were not supported in GAFYD.
> I wish they were :-/ The message says "Sorry, this module cannot be
> displayed, as it requires inlining but is provided by an untrusted
> source." I would just like to be able to add my gadget URL to the list
> of trusted sources.
> I think that a domain admin for GAFYD takes over from Google's
> responsibility to proactively proetect users from potential attacks.
> If the GAFYD admin user deems a gadget as safe, then that's their
> decision and they should be able to pre-add whichever (currently
> existing) inlined gadget are required. This is not the same as
> allowing non-admin GAFYD from adding inlined gadgets.
> I'm exploring this as I've recently been inundated with gadget
> requests for GAFYD and have just remembered from re-reading posts in
> this group that I will be unable to help out. Is there any possibility
> of this being changed before the switch is flipped please?
> On Nov 9, 11:17 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> > Hey Matt,
> > Thanks for the valuable feedback. Comments below:
> > > Many of the gadgets I develop are for my own use - I don't even care
> > > if anyone else uses them. I find it very handy to use inlined gadgets
> > > because I can do more with them and I don't have to deal with the
> > > issues of iframes, resizing, etc. Inline gadgets just work better,
> > > IMO. Even if they aren't popular, what's the harm in allowing them to
> > > continue to be created? If users don't mind the security "risks" why
> > > reduce their choice? You're effectively turning of all access to
> > > skinning the igoogle page, correct?
> > You do bring up an interesting point. You may be right that some
> > users don't mind the security risks, but part of our job is to pro-
> > actively protect our users from potential attacks. It wasn't an easy
> > decision to make, but the fact is that inlined gadgets has always
> > compromised security in various ways. The truth is that many users do
> > get scared away from the opt-in message that gets displayed when
> > adding a third-party inlined gadget. So I do think we need to keep
> > this in mind.
> > In addition to security, there are other complications and limitations
> > surrounding inlined gadgets such as the inability to add them to other
> > pages, etc. However, this is probably irrelevant to someone who
> > really wants to use inlined gadgets for their own personal use.
> > > 1) Can I update the XML of an inlined gadget that already exists, once
> > > you have flipped the switch?
> > Yes. After the switch is flipped, you can continue to update inlined
> > gadget as you normally would.
> > > 2) If so, can I add, say, 10 inlined gadgets right now as
> > > "placeholders" and then modify the XML in the future to create a
> > > different gadget?
> > Possibly, which is part of the reason why I posted the announcement in
> > advance. However, I can't guarantee that they'll make it in since
> > they'll probably have very low traffic. I'd go ahead and create them
> > anyway as you might as well try.
> > > 3) Will inlined gadgets only continue to work if they exist in the
> > > directory? Or if I've added them by url, will they continue to work?
> > Inlined gadgets do not have to exist in the directory to be qualified
> > although you should make sure they are getting some volume of traffic.
> > > Would you consider opening that up a bit more and allowing iframe
> > > gadgets to do more things to their containing page? That would at
> > > least allow for skinning, gadgets with icons in their header bars,
> > > etc. If I couldn't use my skin gadget, iGoogle would be much less
> > > usable to me because of real estate issues, colors, etc.
> > Yes, technically this would be possible and may help with the
> > transition. However I don't have any updates on whether this will be
> > available in the near future. These are container-specific features
> > that only apply to iGoogle. So there's naturally going to be some
> > debate over how useful this would be to the general public.
> I hear your point, but I do think this is somewhat of a separate
> discussion. GAFYD has never supported inlined gadgets, and I'm sure
> there's reasons why the GAFYD team decided not to enable them. I'd
> recommend posting these concerns in the GAFYD discussion group as I
> imagine you'll find more answers there. The question of enabling
> inlined gadgets in other Google properties is more dependent on that
> specific property as opposed to gadgets as a whole. So unfortunately,
> I won't be able to help with this.
> Sorry!
> Dann
> On Nov 10, 2:51 am, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> > I read in this group that inlined gadget were not supported in GAFYD.
> > I wish they were :-/ The message says "Sorry, this module cannot be
> > displayed, as it requires inlining but is provided by an untrusted
> > source." I would just like to be able to add my gadget URL to the list
> > of trusted sources.
> > I think that a domain admin for GAFYD takes over from Google's
> > responsibility to proactively proetect users from potential attacks.
> > If the GAFYD admin user deems a gadget as safe, then that's their
> > decision and they should be able to pre-add whichever (currently
> > existing) inlined gadget are required. This is not the same as
> > allowing non-admin GAFYD from adding inlined gadgets.
> > I'm exploring this as I've recently been inundated with gadget
> > requests for GAFYD and have just remembered from re-reading posts in
> > this group that I will be unable to help out. Is there any possibility
> > of this being changed before the switch is flipped please?
> > On Nov 9, 11:17 pm, "Dann (Google Employee)" <d...@google.com> wrote:
> > > Hey Matt,
> > > Thanks for the valuable feedback. Comments below:
> > > > Many of the gadgets I develop are for my own use - I don't even care
> > > > if anyone else uses them. I find it very handy to use inlined gadgets
> > > > because I can do more with them and I don't have to deal with the
> > > > issues of iframes, resizing, etc. Inline gadgets just work better,
> > > > IMO. Even if they aren't popular, what's the harm in allowing them to
> > > > continue to be created? If users don't mind the security "risks" why
> > > > reduce their choice? You're effectively turning of all access to
> > > > skinning the igoogle page, correct?
> > > You do bring up an interesting point. You may be right that some
> > > users don't mind the security risks, but part of our job is to pro-
> > > actively protect our users from potential attacks. It wasn't an easy
> > > decision to make, but the fact is that inlined gadgets has always
> > > compromised security in various ways. The truth is that many users do
> > > get scared away from the opt-in message that gets displayed when
> > > adding a third-party inlined gadget. So I do think we need to keep
> > > this in mind.
> > > In addition to security, there are other complications and limitations
> > > surrounding inlined gadgets such as the inability to add them to other
> > > pages, etc. However, this is probably irrelevant to someone who
> > > really wants to use inlined gadgets for their own personal use.
> > > > 1) Can I update the XML of an inlined gadget that already exists, once
> > > > you have flipped the switch?
> > > Yes. After the switch is flipped, you can continue to update inlined
> > > gadget as you normally would.
> > > > 2) If so, can I add, say, 10 inlined gadgets right now as
> > > > "placeholders" and then modify the XML in the future to create a
> > > > different gadget?
> > > Possibly, which is part of the reason why I posted the announcement in
> > > advance. However, I can't guarantee that they'll make it in since
> > > they'll probably have very low traffic. I'd go ahead and create them
> > > anyway as you might as well try.
> > > > 3) Will inlined gadgets only continue to work if they exist in the
> > > > directory? Or if I've added them by url, will they continue to work?
> > > Inlined gadgets do not have to exist in the directory to be qualified
> > > although you should make sure they are getting some volume of traffic.
> > > > Would you consider opening that up a bit more and allowing iframe
> > > > gadgets to do more things to their containing page? That would at
> > > > least allow for skinning, gadgets with icons in their header bars,
> > > > etc. If I couldn't use my skin gadget, iGoogle would be much less
> > > > usable to me because of real estate issues, colors, etc.
> > > Yes, technically this would be possible and may help with the
> > > transition. However I don't have any updates on whether this will be
> > > available in the near future. These are container-specific features
> > > that only apply to iGoogle. So there's naturally going to be some
> > > debate over how useful this would be to the general public.
Discussion subject changed to "README: Inlined (type="html-inline") Gadgets To Be Deprecated NEXT WEEK -- (UPDATED 2007-12-07)" by Dann (Google Employee)
The time is near everyone. By middle of next week, inlined gadgets
will officially become deprecated and blocked from being rendered on
iGoogle. As promised, we will take a snapshot of all inlined gadgets
that currently exist and specifically allow only those that were
collected to continue rendering. When will this happen? We'll be
taking a snapshot this coming ***Monday, 2007-12-10***. Once again,
please note that we won't be accepting any requests to add a new
inlined gadget to the list after this date. I apologize in advance to
those of you who don't get this message in time, but it's a necessary
step in successfully deprecating this feature.
Our documentation has recently been updated to remove all references
to inlined (type="html-inline") gadgets. Existing authors, we still
encourage you to ask your questions about inlined gadgets in this
group, and we'll continue to do our best to support you. However at
this point, we assume and hope that by now, you're all already
familiar with the many caveats and exceptions that come with building
an inlined gadget. If you need a reminder though, we're always here
to help :)
Next week, I'll post another final announcement to this thread once
the switch is turned on. It's really an exciting time for gadgets,
and this will indefinitely increase the potential of gadgets even
more. We hope this change doesn't inconvenience too many of you, and
we're always open to hear your comments.
Thanks again!
Dann
On Nov 8, 10:03 am, "Dann (Google Employee)" <d...@google.com> wrote:
> Realizing that this may be a sensitive topic, I want to give everyone
> *advanced* notice that inlined gadgets (type="html-inline") will soon
> be deprecated from the Gadgets API.
> This is an important announcement which I hope will reach as many
> developers as possible. For authors of existing inlined gadgets, you
> needn't worry. Your gadgets will continue working as normal. There
> are some subtleties around what this exactly means, and I'll try to
> explain them below. I don't have an ETA on when this will happen, but
> please expect for it to happen soon. The main goal is to give you all
> a heads up about this change. Feel free to post questions, and I'll
> do my best to answer them.
> ====
> What does this mean?
> The deprecation of inlined gadgets means that new inlined gadgets can
> no longer be created after we turn on the switch. For inlined gadgets
> that already exist, they will continue to be supported and render as
> normal. This will just prevent any new inlined gadgets from being
> created. I can't announce exactly when we'll start the deprecation,
> but the earlier you start, the better the chances you'll make it in
> time.
> Why?
> Inlined gadgets pose potential security risks to our users in addition
> to other complications with some API libraries, e.g. Analytics.
> They're more difficult to develop and cannot be syndicated via Google
> Gadgets For Your Webpage. This is one of the major reasons why
> inlined gadgets are generally less discoverable and don't get as much
> traffic as type="html" gadgets. Supporting inlined gadgets can be
> difficult because many inlined gadgets depend on specific DOM elements
> in the iGoogle container page. The container page can frequently
> change and essentially break your gadget. Just ask Bonstio and
> Matt ;). By deprecating inlined gadgets, it allows us to standardize
> the way gadgets are rendered and create a more consistent API
> resulting in a better developer experience.
> Will inlined gadgets be closed forever?
> Initially, we will not be honoring requests to add additional inlined
> gadgets. In the future, we may consider allowing developers to submit
> a proposal to develop an inlined gadget and have it go through an
> approvals process. However, please understand that this is purely
> hypothetical at this point with no ETA. The current plan is that once
> we deprecate inlining, we will stop allowing new inlined gadgets,
> without exceptions.
> Feedback?
> This announcement is intended to give advanced notice of this upcoming
> change. Feel free to post comments/questions, and I'll do my best to
> answer them.
Will the snapshot also take into account those low traffic development
versions of gadgets which many of use to test? Would it be helpful to
let you know the specific urls of these gadgets?
Thanks!
On Dec 8, 1:43 am, "Dann (Google Employee)" <d...@google.com> wrote:
> The time is near everyone. By middle of next week, inlined gadgets
> will officially become deprecated and blocked from being rendered on
> iGoogle. As promised, we will take a snapshot of all inlined gadgets
> that currently exist and specifically allow only those that were
> collected to continue rendering. When will this happen? We'll be
> taking a snapshot this coming ***Monday, 2007-12-10***. Once again,
> please note that we won't be accepting any requests to add a new
> inlined gadget to the list after this date. I apologize in advance to
> those of you who don't get this message in time, but it's a necessary
> step in successfully deprecating this feature.
> Our documentation has recently been updated to remove all references
> to inlined (type="html-inline") gadgets. Existing authors, we still
> encourage you to ask your questions about inlined gadgets in this
> group, and we'll continue to do our best to support you. However at
> this point, we assume and hope that by now, you're all already
> familiar with the many caveats and exceptions that come with building
> an inlined gadget. If you need a reminder though, we're always here
> to help :)
> Next week, I'll post another final announcement to this thread once
> the switch is turned on. It's really an exciting time for gadgets,
> and this will indefinitely increase the potential of gadgets even
> more. We hope this change doesn't inconvenience too many of you, and
> we're always open to hear your comments.
> Thanks again!
> Dann
> On Nov 8, 10:03 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > Hey everyone,
> > Realizing that this may be a sensitive topic, I want to give everyone
> > *advanced* notice that inlined gadgets (type="html-inline") will soon
> > be deprecated from the Gadgets API.
> > This is an important announcement which I hope will reach as many
> > developers as possible. For authors of existing inlined gadgets, you
> > needn't worry. Your gadgets will continue working as normal. There
> > are some subtleties around what this exactly means, and I'll try to
> > explain them below. I don't have an ETA on when this will happen, but
> > please expect for it to happen soon. The main goal is to give you all
> > a heads up about this change. Feel free to post questions, and I'll
> > do my best to answer them.
> > ====
> > What does this mean?
> > The deprecation of inlined gadgets means that new inlined gadgets can
> > no longer be created after we turn on the switch. For inlined gadgets
> > that already exist, they will continue to be supported and render as
> > normal. This will just prevent any new inlined gadgets from being
> > created. I can't announce exactly when we'll start the deprecation,
> > but the earlier you start, the better the chances you'll make it in
> > time.
> > Why?
> > Inlined gadgets pose potential security risks to our users in addition
> > to other complications with some API libraries, e.g. Analytics.
> > They're more difficult to develop and cannot be syndicated via Google
> > Gadgets For Your Webpage. This is one of the major reasons why
> > inlined gadgets are generally less discoverable and don't get as much
> > traffic as type="html" gadgets. Supporting inlined gadgets can be
> > difficult because many inlined gadgets depend on specific DOM elements
> > in the iGoogle container page. The container page can frequently
> > change and essentially break your gadget. Just ask Bonstio and
> > Matt ;). By deprecating inlined gadgets, it allows us to standardize
> > the way gadgets are rendered and create a more consistent API
> > resulting in a better developer experience.
> > Will inlined gadgets be closed forever?
> > Initially, we will not be honoring requests to add additional inlined
> > gadgets. In the future, we may consider allowing developers to submit
> > a proposal to develop an inlined gadget and have it go through an
> > approvals process. However, please understand that this is purely
> > hypothetical at this point with no ETA. The current plan is that once
> > we deprecate inlining, we will stop allowing new inlined gadgets,
> > without exceptions.
> > Feedback?
> > This announcement is intended to give advanced notice of this upcoming
> > change. Feel free to post comments/questions, and I'll do my best to
> > answer them.
> Will the snapshot also take into account those low traffic development
> versions of gadgets which many of use to test? Would it be helpful to
> let you know the specific urls of these gadgets?
> Thanks!
> On Dec 8, 1:43 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > Please read below for an update on this topic!
> > The time is near everyone. By middle of next week, inlined gadgets
> > will officially become deprecated and blocked from being rendered on
> > iGoogle. As promised, we will take a snapshot of all inlined gadgets
> > that currently exist and specifically allow only those that were
> > collected to continue rendering. When will this happen? We'll be
> > taking a snapshot this coming ***Monday, 2007-12-10***. Once again,
> > please note that we won't be accepting any requests to add a new
> > inlined gadget to the list after this date. I apologize in advance to
> > those of you who don't get this message in time, but it's a necessary
> > step in successfully deprecating this feature.
> > Our documentation has recently been updated to remove all references
> > to inlined (type="html-inline") gadgets. Existing authors, we still
> > encourage you to ask your questions about inlined gadgets in this
> > group, and we'll continue to do our best to support you. However at
> > this point, we assume and hope that by now, you're all already
> > familiar with the many caveats and exceptions that come with building
> > an inlined gadget. If you need a reminder though, we're always here
> > to help :)
> > Next week, I'll post another final announcement to this thread once
> > the switch is turned on. It's really an exciting time for gadgets,
> > and this will indefinitely increase the potential of gadgets even
> > more. We hope this change doesn't inconvenience too many of you, and
> > we're always open to hear your comments.
> > Thanks again!
> > Dann
> > On Nov 8, 10:03 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > > Hey everyone,
> > > Realizing that this may be a sensitive topic, I want to give everyone
> > > *advanced* notice that inlined gadgets (type="html-inline") will soon
> > > be deprecated from the Gadgets API.
> > > This is an important announcement which I hope will reach as many
> > > developers as possible. For authors of existing inlined gadgets, you
> > > needn't worry. Your gadgets will continue working as normal. There
> > > are some subtleties around what this exactly means, and I'll try to
> > > explain them below. I don't have an ETA on when this will happen, but
> > > please expect for it to happen soon. The main goal is to give you all
> > > a heads up about this change. Feel free to post questions, and I'll
> > > do my best to answer them.
> > > ====
> > > What does this mean?
> > > The deprecation of inlined gadgets means that new inlined gadgets can
> > > no longer be created after we turn on the switch. For inlined gadgets
> > > that already exist, they will continue to be supported and render as
> > > normal. This will just prevent any new inlined gadgets from being
> > > created. I can't announce exactly when we'll start the deprecation,
> > > but the earlier you start, the better the chances you'll make it in
> > > time.
> > > Why?
> > > Inlined gadgets pose potential security risks to our users in addition
> > > to other complications with some API libraries, e.g. Analytics.
> > > They're more difficult to develop and cannot be syndicated via Google
> > > Gadgets For Your Webpage. This is one of the major reasons why
> > > inlined gadgets are generally less discoverable and don't get as much
> > > traffic as type="html" gadgets. Supporting inlined gadgets can be
> > > difficult because many inlined gadgets depend on specific DOM elements
> > > in the iGoogle container page. The container page can frequently
> > > change and essentially break your gadget. Just ask Bonstio and
> > > Matt ;). By deprecating inlined gadgets, it allows us to standardize
> > > the way gadgets are rendered and create a more consistent API
> > > resulting in a better developer experience.
> > > Will inlined gadgets be closed forever?
> > > Initially, we will not be honoring requests to add additional inlined
> > > gadgets. In the future, we may consider allowing developers to submit
> > > a proposal to develop an inlined gadget and have it go through an
> > > approvals process. However, please understand that this is purely
> > > hypothetical at this point with no ETA. The current plan is that once
> > > we deprecate inlining, we will stop allowing new inlined gadgets,
> > > without exceptions.
> > > Feedback?
> > > This announcement is intended to give advanced notice of this upcoming
> > > change. Feel free to post comments/questions, and I'll do my best to
> > > answer them.
Sorry if this wasn't clear in my previous post, but the cut-off point
is today, Monday 12/10. We'll be gathering the URLs for *all* inlined
gadgets, even those with low traffic. People with development
versions of their gadget as Bonstio pointed out should be OK. Sending
us the specific URLs won't help because it opens up the flood doors
for accepting manual requests to get added. Unfortunately we can't do
that at this time.
Hope this answers some of your questions.
Thanks,
Dann
On Dec 9, 2:11 am, Simon <qila...@gmail.com> wrote:
> It would also be good to know what the cut-off point is for live
> gadgets traffic-wise.
> On Dec 8, 10:15 am, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> > Hi Dann,
> > Will the snapshot also take into account those low traffic development
> > versions of gadgets which many of use to test? Would it be helpful to
> > let you know the specific urls of these gadgets?
> > Thanks!
> > On Dec 8, 1:43 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > > Please read below for an update on this topic!
> > > The time is near everyone. By middle of next week, inlined gadgets
> > > will officially become deprecated and blocked from being rendered on
> > > iGoogle. As promised, we will take a snapshot of all inlined gadgets
> > > that currently exist and specifically allow only those that were
> > > collected to continue rendering. When will this happen? We'll be
> > > taking a snapshot this coming ***Monday, 2007-12-10***. Once again,
> > > please note that we won't be accepting any requests to add a new
> > > inlined gadget to the list after this date. I apologize in advance to
> > > those of you who don't get this message in time, but it's a necessary
> > > step in successfully deprecating this feature.
> > > Our documentation has recently been updated to remove all references
> > > to inlined (type="html-inline") gadgets. Existing authors, we still
> > > encourage you to ask your questions about inlined gadgets in this
> > > group, and we'll continue to do our best to support you. However at
> > > this point, we assume and hope that by now, you're all already
> > > familiar with the many caveats and exceptions that come with building
> > > an inlined gadget. If you need a reminder though, we're always here
> > > to help :)
> > > Next week, I'll post another final announcement to this thread once
> > > the switch is turned on. It's really an exciting time for gadgets,
> > > and this will indefinitely increase the potential of gadgets even
> > > more. We hope this change doesn't inconvenience too many of you, and
> > > we're always open to hear your comments.
> > > Thanks again!
> > > Dann
> > > On Nov 8, 10:03 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > > > Hey everyone,
> > > > Realizing that this may be a sensitive topic, I want to give everyone
> > > > *advanced* notice that inlined gadgets (type="html-inline") will soon
> > > > be deprecated from the Gadgets API.
> > > > This is an important announcement which I hope will reach as many
> > > > developers as possible. For authors of existing inlined gadgets, you
> > > > needn't worry. Your gadgets will continue working as normal. There
> > > > are some subtleties around what this exactly means, and I'll try to
> > > > explain them below. I don't have an ETA on when this will happen, but
> > > > please expect for it to happen soon. The main goal is to give you all
> > > > a heads up about this change. Feel free to post questions, and I'll
> > > > do my best to answer them.
> > > > ====
> > > > What does this mean?
> > > > The deprecation of inlined gadgets means that new inlined gadgets can
> > > > no longer be created after we turn on the switch. For inlined gadgets
> > > > that already exist, they will continue to be supported and render as
> > > > normal. This will just prevent any new inlined gadgets from being
> > > > created. I can't announce exactly when we'll start the deprecation,
> > > > but the earlier you start, the better the chances you'll make it in
> > > > time.
> > > > Why?
> > > > Inlined gadgets pose potential security risks to our users in addition
> > > > to other complications with some API libraries, e.g. Analytics.
> > > > They're more difficult to develop and cannot be syndicated via Google
> > > > Gadgets For Your Webpage. This is one of the major reasons why
> > > > inlined gadgets are generally less discoverable and don't get as much
> > > > traffic as type="html" gadgets. Supporting inlined gadgets can be
> > > > difficult because many inlined gadgets depend on specific DOM elements
> > > > in the iGoogle container page. The container page can frequently
> > > > change and essentially break your gadget. Just ask Bonstio and
> > > > Matt ;). By deprecating inlined gadgets, it allows us to standardize
> > > > the way gadgets are rendered and create a more consistent API
> > > > resulting in a better developer experience.
> > > > Will inlined gadgets be closed forever?
> > > > Initially, we will not be honoring requests to add additional inlined
> > > > gadgets. In the future, we may consider allowing developers to submit
> > > > a proposal to develop an inlined gadget and have it go through an
> > > > approvals process. However, please understand that this is purely
> > > > hypothetical at this point with no ETA. The current plan is that once
> > > > we deprecate inlining, we will stop allowing new inlined gadgets,
> > > > without exceptions.
> > > > Feedback?
> > > > This announcement is intended to give advanced notice of this upcoming
> > > > change. Feel free to post comments/questions, and I'll do my best to
> > > > answer them.
> Sorry if this wasn't clear in my previous post, but the cut-off point
> is today, Monday 12/10. We'll be gathering the URLs for *all* inlined
> gadgets, even those with low traffic. People with development
> versions of their gadget as Bonstio pointed out should be OK. Sending
> us the specific URLs won't help because it opens up the flood doors
> for accepting manual requests to get added. Unfortunately we can't do
> that at this time.
> Hope this answers some of your questions.
> Thanks,
> Dann
> On Dec 9, 2:11 am, Simon <qila...@gmail.com> wrote:
> > It would also be good to know what the cut-off point is for live
> > gadgets traffic-wise.
> > On Dec 8, 10:15 am, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> > > Hi Dann,
> > > Will the snapshot also take into account those low traffic development
> > > versions of gadgets which many of use to test? Would it be helpful to
> > > let you know the specific urls of these gadgets?
> > > Thanks!
> > > On Dec 8, 1:43 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > > > Please read below for an update on this topic!
> > > > The time is near everyone. By middle of next week, inlined gadgets
> > > > will officially become deprecated and blocked from being rendered on
> > > > iGoogle. As promised, we will take a snapshot of all inlined gadgets
> > > > that currently exist and specifically allow only those that were
> > > > collected to continue rendering. When will this happen? We'll be
> > > > taking a snapshot this coming ***Monday, 2007-12-10***. Once again,
> > > > please note that we won't be accepting any requests to add a new
> > > > inlined gadget to the list after this date. I apologize in advance to
> > > > those of you who don't get this message in time, but it's a necessary
> > > > step in successfully deprecating this feature.
> > > > Our documentation has recently been updated to remove all references
> > > > to inlined (type="html-inline") gadgets. Existing authors, we still
> > > > encourage you to ask your questions about inlined gadgets in this
> > > > group, and we'll continue to do our best to support you. However at
> > > > this point, we assume and hope that by now, you're all already
> > > > familiar with the many caveats and exceptions that come with building
> > > > an inlined gadget. If you need a reminder though, we're always here
> > > > to help :)
> > > > Next week, I'll post another final announcement to this thread once
> > > > the switch is turned on. It's really an exciting time for gadgets,
> > > > and this will indefinitely increase the potential of gadgets even
> > > > more. We hope this change doesn't inconvenience too many of you, and
> > > > we're always open to hear your comments.
> > > > Thanks again!
> > > > Dann
> > > > On Nov 8, 10:03 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > > > > Hey everyone,
> > > > > Realizing that this may be a sensitive topic, I want to give everyone
> > > > > *advanced* notice that inlined gadgets (type="html-inline") will soon
> > > > > be deprecated from the Gadgets API.
> > > > > This is an important announcement which I hope will reach as many
> > > > > developers as possible. For authors of existing inlined gadgets, you
> > > > > needn't worry. Your gadgets will continue working as normal. There
> > > > > are some subtleties around what this exactly means, and I'll try to
> > > > > explain them below. I don't have an ETA on when this will happen, but
> > > > > please expect for it to happen soon. The main goal is to give you all
> > > > > a heads up about this change. Feel free to post questions, and I'll
> > > > > do my best to answer them.
> > > > > ====
> > > > > What does this mean?
> > > > > The deprecation of inlined gadgets means that new inlined gadgets can
> > > > > no longer be created after we turn on the switch. For inlined gadgets
> > > > > that already exist, they will continue to be supported and render as
> > > > > normal. This will just prevent any new inlined gadgets from being
> > > > > created. I can't announce exactly when we'll start the deprecation,
> > > > > but the earlier you start, the better the chances you'll make it in
> > > > > time.
> > > > > Why?
> > > > > Inlined gadgets pose potential security risks to our users in addition
> > > > > to other complications with some API libraries, e.g. Analytics.
> > > > > They're more difficult to develop and cannot be syndicated via Google
> > > > > Gadgets For Your Webpage. This is one of the major reasons why
> > > > > inlined gadgets are generally less discoverable and don't get as much
> > > > > traffic as type="html" gadgets. Supporting inlined gadgets can be
> > > > > difficult because many inlined gadgets depend on specific DOM elements
> > > > > in the iGoogle container page. The container page can frequently
> > > > > change and essentially break your gadget. Just ask Bonstio and
> > > > > Matt ;). By deprecating inlined gadgets, it allows us to standardize
> > > > > the way gadgets are rendered and create a more consistent API
> > > > > resulting in a better developer experience.
> > > > > Will inlined gadgets be closed forever?
> > > > > Initially, we will not be honoring requests to add additional inlined
> > > > > gadgets. In the future, we may consider allowing developers to submit
> > > > > a proposal to develop an inlined gadget and have it go through an
> > > > > approvals process. However, please understand that this is purely
> > > > > hypothetical at this point with no ETA. The current plan is that once
> > > > > we deprecate inlining, we will stop allowing new inlined gadgets,
> > > > > without exceptions.
> > > > > Feedback?
> > > > > This announcement is intended to give advanced notice of this upcoming
> > > > > change. Feel free to post comments/questions, and I'll do my best to
> > > > > answer them.
Many of my gadgets are inline because they add animals and such to the
whole page (Ladybugs, butterflies, Snow, etc). They are quite
popular. I have more than a few ideas for other such "things" to be
added to the page. Someone suggested hearts that float around. I was
just planning on doing that when I came across this post.
I am highly disappointed that they won't be acceptable from this point
on. I understand the security risks and, yes, there are people put
off by the security check. I believe that not allowing future inline
modules is a disservice to the users. It was one of the features that
was unique to iGoogle that put it above the rest (live.com, netvibes,
my yahoo, etc). It enabled some unique functionality. Could the
gadgets be broken by changes to the iGoogle homepage? yes. But
authors of inline gadgets just needed to accept that and adapt to the
changes. That's not such a bad thing, it forces better code
standards.
In a way this move forces inline modules underground if modules can be
added but not be in the directory. I'm not so sure that is a good
idea as it lessens the ability to scrutinize the modules. If there
was something awful about a module "being a bad inline module" then
surely it would be picked up by some javascripter whom views the
source or by someone with one of the various Firefox plug-ins that
monitor network traffic.
In short, I always admired Google's ability to think outside the
box... or at least enable things outside the box. If my Living Page
module users (the sum of all my gadgets that live on the page) knew
what was going on I'm sure they'd be very disappointed to never see
any new Living Page modules created from this point on.
I'd like to say that it's pretty cool how you've change the gadget
search ranking to make inline gadgets so much less relevant. It's
also really neat how inline gadgets don't affect author ranking any
more. Lovely.
Does this all mean that new users can't add inline gadgets? That's
the way it seem to be working today. I went to add a few of my
gadgets in the directory and I'm getting the error message the they
aren't supported any more.
All gadgets are equal, but some gadgets are more equal than others.
I wrote an inline gadget for a few disabled friends that greatly
improved the usability of iGoogle. It has existed on the GooglePages
server for many months, but stopped working today.
Dann (Google Employee) wrote:
> Sorry if this wasn't clear in my previous post, but the cut-off point
> is today, Monday 12/10. We'll be gathering the URLs for *all* inlined
> gadgets, even those with low traffic. People with development
> versions of their gadget as Bonstio pointed out should be OK. Sending
> us the specific URLs won't help because it opens up the flood doors
> for accepting manual requests to get added. Unfortunately we can't do
> that at this time.
> Hope this answers some of your questions.
> Thanks,
> Dann
> On Dec 9, 2:11 am, Simon <qila...@gmail.com> wrote:
> > It would also be good to know what the cut-off point is for live
> > gadgets traffic-wise.
> > On Dec 8, 10:15 am, "Bonstio (Guru)" <bons...@gmail.com> wrote:
> > > Hi Dann,
> > > Will the snapshot also take into account those low traffic development
> > > versions of gadgets which many of use to test? Would it be helpful to
> > > let you know the specific urls of these gadgets?
> > > Thanks!
> > > On Dec 8, 1:43 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > > > Please read below for an update on this topic!
> > > > The time is near everyone. By middle of next week, inlined gadgets
> > > > will officially become deprecated and blocked from being rendered on
> > > > iGoogle. As promised, we will take a snapshot of all inlined gadgets
> > > > that currently exist and specifically allow only those that were
> > > > collected to continue rendering. When will this happen? We'll be
> > > > taking a snapshot this coming ***Monday, 2007-12-10***. Once again,
> > > > please note that we won't be accepting any requests to add a new
> > > > inlined gadget to the list after this date. I apologize in advance to
> > > > those of you who don't get this message in time, but it's a necessary
> > > > step in successfully deprecating this feature.
> > > > Our documentation has recently been updated to remove all references
> > > > to inlined (type="html-inline") gadgets. Existing authors, we still
> > > > encourage you to ask your questions about inlined gadgets in this
> > > > group, and we'll continue to do our best to support you. However at
> > > > this point, we assume and hope that by now, you're all already
> > > > familiar with the many caveats and exceptions that come with building
> > > > an inlined gadget. If you need a reminder though, we're always here
> > > > to help :)
> > > > Next week, I'll post another final announcement to this thread once
> > > > the switch is turned on. It's really an exciting time for gadgets,
> > > > and this will indefinitely increase the potential of gadgets even
> > > > more. We hope this change doesn't inconvenience too many of you, and
> > > > we're always open to hear your comments.
> > > > Thanks again!
> > > > Dann
> > > > On Nov 8, 10:03 am, "Dann (Google Employee)" <d...@google.com> wrote:
> > > > > Hey everyone,
> > > > > Realizing that this may be a sensitive topic, I want to give everyone
> > > > > *advanced* notice that inlined gadgets (type="html-inline") will soon
> > > > > be deprecated from the Gadgets API.
> > > > > This is an important announcement which I hope will reach as many
> > > > > developers as possible. For authors of existing inlined gadgets, you
> > > > > needn't worry. Your gadgets will continue working as normal. There
> > > > > are some subtleties around what this exactly means, and I'll try to
> > > > > explain them below. I don't have an ETA on when this will happen, but
> > > > > please expect for it to happen soon. The main goal is to give you all
> > > > > a heads up about this change. Feel free to post questions, and I'll
> > > > > do my best to answer them.
> > > > > ====
> > > > > What does this mean?
> > > > > The deprecation of inlined gadgets means that new inlined gadgets can
> > > > > no longer be created after we turn on the switch. For inlined gadgets
> > > > > that already exist, they will continue to be supported and render as
> > > > > normal. This will just prevent any new inlined gadgets from being
> > > > > created. I can't announce exactly when we'll start the deprecation,
> > > > > but the earlier you start, the better the chances you'll make it in
> > > > > time.
> > > > > Why?
> > > > > Inlined gadgets pose potential security risks to our users in addition
> > > > > to other complications with some API libraries, e.g. Analytics.
> > > > > They're more difficult to develop and cannot be syndicated via Google
> > > > > Gadgets For Your Webpage. This is one of the major reasons why
> > > > > inlined gadgets are generally less discoverable and don't get as much
> > > > > traffic as type="html" gadgets. Supporting inlined gadgets can be
> > > > > difficult because many inlined gadgets depend on specific DOM elements
> > > > > in the iGoogle container page. The container page can frequently
> > > > > change and essentially break your gadget. Just ask Bonstio and
> > > > > Matt ;). By deprecating inlined gadgets, it allows us to standardize
> > > > > the way gadgets are rendered and create a more consistent API
> > > > > resulting in a better developer experience.
> > > > > Will inlined gadgets be closed forever?
> > > > > Initially, we will not be honoring requests to add additional inlined
> > > > > gadgets. In the future, we may consider allowing developers to submit
> > > > > a proposal to develop an inlined gadget and have it go through an
> > > > > approvals process. However, please understand that this is purely
> > > > > hypothetical at this point with no ETA. The current plan is that once
> > > > > we deprecate inlining, we will stop allowing new inlined gadgets,
> > > > > without exceptions.
> > > > > Feedback?
> > > > > This announcement is intended to give advanced notice of this upcoming
> > > > > change. Feel free to post comments/questions, and I'll do my best to
> > > > > answer them.
Hi Dann
So the dog example in this page doesn't work any more as it has html-
inline command:
http://code.google.com/apis/gadgets/docs/ui.html <Content type="html">
My question; is there is an alternative to this command, for me it is
very important to be able to create gadgets based on flash files and I
have been doing that using the code below :
<Content type="html"><
|
