Hi Troy, The short answer to your question is that "No", your gadget can't access the email address of the current user, without somewhat ugly tricks like using 3-legged OAuth to access the Contacts API.
However, there is a way to get contextual data from the container, in Calendar. See this doc on sidebar gadgets (which were launched recently): http://code.google.com/apis/calendar/gadgets/sidebar/. You can register handlers for when the current date changes, new events are added, etc. The details of these events are also available through the API. I think this is roughly along the lines of what you are looking for, but in the Calendar context instead of the Gmail context. I hope this helps, and let me know if you have any questions. Thanks, Dan On Sep 20, 12:35 pm, Troy Davis <[email protected]> wrote: > 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 Cloudvoxhttp://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 -~----------~----~----~----~------~----~------~--~---
