Hi String, I feel your pain, but the gadgets API in Gmail is, as you note, a Gmail Labs feature which bears the warning: "They may change, break or disappear at any time." From a formal standpoint, there isn't any documentation, nor was there a developer blog or group when you started using the API. I'd agree on calling out a communications failure if these channels existed and were silent, but they do not exist and I believe the Gmail team set expectations accordingly.
Dan On Apr 30, 3:02 am, String <[email protected]> wrote: > Code-breaking change to gadget support on Gmail > > Sometime in the last 48 hours, a change was made to the Gmail gadgets > platform that broke most of my gadgets. I've been digging into it > since I noticed the change (time permitting), and here's what I've > found. > > Previously, gadgets were served from subdomains of gmodules.com, such > as: > > http://1.gmail.gmodules.comhttp://2.gmail.gmodules.com > > Where each gadget on the page had a different number at the beginning. > This is congruent with iGoogle gadgets generally, they've always been > served from gmodules.com, regardless of host platform. > > Now, the host for Gmail gadget iframes look like this: > > https://psglh63b1qffbcf6jeem59as0o0j9vro-a-gm-opensocial.googleuserco...https://lukvq4do2r6js9qajiqsd92jqq9p3qel-a-gm-opensocial.googleuserco... > > Again, the exact subdomain is different, but apparently the long > string at the beginning is a hash of the gadget URL - you can't serve > one gadget from another's subdomain, whereas before, the numbers were > generic. That's no big deal, and might actually enhance security. > > But note the base domain is different. This in itself broke all my map > gadgets at a stroke. The GMaps API requires a domain-specific key, and > while it recognizes certain domains (like gmodules.com) as Google- > owned and not requiring a key, googleusercontent.com isn't one of > them. There is a workaround (register an API key for > googleusercontent.com), but it requires changing the gadget source > code. > > The other issue, affecting non-map gadgets as well, is that the iframe > is now served via HTTPS. This is good, in that the mixed content > security warning can now be avoided on IE, but there's a serious > downside. For gadgets that retrieve additional content via XHR, those > retrievals now fail if they don't also use HTTPS. So again, a code > change is required to make any such gadgets work again on Gmail. > > Here's the bottom line: This is abominable behavior from Google for a > published API, even one that is still in Labs. The very least they > could have done was warn us that this was coming, on the Gmail Gadgets > Developer's Group... what's that you say, there is no such group? Oh > yeah, there is that small problem. There isn't anywhere that support > is offered for this. > > Come on Google, you know better than to treat developers like this. > Communication is vital. > > String > > ------------- > Cross-posted at the Gmail Labs Help Add Any Gadget group and the > iGoogle Developer Forum because, like I said, the gadgets API on Gmail > is an illegitimate child and doesn't have a group of its own. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iGoogle Developer Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Gadgets-API?hl=en -~----------~----~----~----~------~----~------~--~---
