Hi Dan, OK, fair enough. I suspect my rant was in the hope that these expectations could be exceeded. :^)
And I'd like to make clear, I think that the changes are for the better - especially the ability to deliver content through SSL, and avoid the warning on IE. I guess I'll just have to wait and hope that some developer support comes along. Thanks for your response, String On Apr 30, 5:50 pm, "Dan (Google)" <[email protected]> wrote: > 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...... > > > 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 -~----------~----~----~----~------~----~------~--~---
