Hi, GMail Labs' gadgets support inspired me to try making a gadget, and I wanted to access the recipient's email address while a GMail user composed a message (to display content related to the recipient).
html-inline gadgets were deprecated for good reason. Since gadget iframes are served from googleusercontent.com, they can't traverse the GMail/container DOM via 'top' or 'parent' (also good). What I'm trying to do seems to be impossible -- and for understandable reasons. A bit of container-chosen data would be really handy, though, so gadgets could adapt to the container they're in. As a gadget author, what I'm looking for is basically a message from the container when something that the container considers interesting (and not top secret) happens. As more gadgets are embedded in mostly non-gadget containers (like GMail and Calendar), they're being used as feature extensions. Most of the ~50 GMail Labs features act on the GMail page. That's what users want/expect them to do, so I don't think one-way access to limited data violates user expectations. The uproar when html-inline was deprecated shows strong developer interest. Has there been any work to let containers provide notification when events happen on the page, or share container-relevant data, without full DOM access? A couple resolutions come to mind: 0) There's already a way to do it that I don't know. 1) Gadgets weren't meant for container-related customization. Even though there's demand for it, it's out of scope, and there's no way for folks to extend GMail with Labs-like context-aware features. "Go back to Greasemonkey." Sad but OK. 2) Let containers respond to RPC requests for DOM attributes, at the expense of gadgets hardcoding to container DOMs, gadget "polling," and containers needing to implement DOM control policies. Yuck to all, and the container dependency is a non-starter. Better: let containers respond to RPC requests for container-related data (not tied to DOM), maybe starting with a set of well-known key/ value pairs that matter to the top few types of container pages -- email reader, calendar. In a calendar example, a gadget could obtain any events that the user scheduled in the last 30 seconds, and react accordingly. Still entails polling and probably delay, but not tied to a container's DOM. 3) Overload Features as a way for gadgets to support only specific types of containers/related data. require="email_container", "calendar_container", etc. Doesn't really solve the message passing. 4) Container-to-gadget equivalent to existing gadget-to-gadget pubsub, either with a container publisher or using HTML5 postMessage (<https:// developer.mozilla.org/En/DOM:window.postMessage>, <http://ejohn.org/blog/postmessage-api-changes/>). An email container would publish an event to the "container" channel when a user started composing (like the registerViewChangeCallback() in GMail Greasemonkey), another when they've moved to the body or 10 seconds has passed, and so on. This would be pretty close to realtime, not introduce more browser requirements than pubsub already has (HTML5 postMessage would), and isn't impossible to standardize. For the user, it would be an understandable "Gadget will have access to most {email,calendar} data" approval (and may be filtered so that not all gadgets get it), yet doesn't yield complete same-domain DOM access. And while the container implementation isn't trivial, it seems simpler than a container author's other choices for supporting third-party content-aware widgets: DIY, inline with DOM chaos, or greasemonkey with almost zero adoption. I didn't see discussion of this in the archives. If it's been covered, already implemented, or I'm in the wrong place, let me know. Troy -- Seven Scale, creators of Cloudvox http://cloudvox.com/ -- call your code: API-driven phone calls --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
