我正在寻找一些关于我“应该”研究什么我被要求记住的特定项目的建议。通过探索各种 Google 技术，我已经这样做了大约 3 天，但似乎没有一个是完全正确的。
我需要为 gmail 整理一些与我为 Windows Outlook 整理的大致相当的东西。我将简要解释一下我为 Outlook 用户所做的工作，让您了解我在寻找什么。我整理了一个 Outlook C# 插件，当 Outlook 在启动时加载它时，它会向 Outlook 界面添加许多可点击的选项卡、按钮和其他各种界面元素。当您单击它们时，我的加载项中的 C# 代码将以各种方式调用以执行各种活动，例如归档当前在由我们的一个 Web 应用程序管理的远程数据库中选择的电子邮件消息。它通过调用可用于任何加载的 AddIn 的各种 Outlook C# API 来提取或操作各种 Outlook“对象”来实现这一点。它在单击按钮时所做的另一件事是调出 AddIn 从 .Net 类“webbrowser 控件”实例创建的 Web 浏览器，本质上是将 chrome 添加到 IE“引擎”。它还将它需要的内容添加到该 Web 浏览器的 DOM 中，以使可能在该浏览器的页面中运行的 javascript 代码可以调用大量的 Add-In C# 函数，本质上为我们的 Web 应用程序提供了一种“询问”的方式我的插件来代表该应用程序创建 Outlook 联系人、任务、消息等。它的要点是，我添加到 Outlook 应用程序的 UI 可用于对我们的应用程序进行各种 Web 服务调用（基于通过 Outlook C# API 可见/可管理的各种 Outlook“对象”的状态），
对于完全不同的 gmail 野兽（而不是 Windows 应用程序和基于浏览器的 Web 应用程序），我需要支持“类似”功能。在调查的过程中，我觉得最近几天我一直在转圈。我开始研究 gmail Sidebar 和 Contextual gadgets，向 gmail 添加一些我自己的大致等效的 UI，但很快发现我无法真正使用它们的任何 gmail API，只能尝试硬塞我已经进入的内容一组由上下文小工具支持的触发 gmail“行为”，我意识到这并不足以支持我想要的。最终，我导航到了一组描述功能支持的 Google Apps 脚本的开发人员页面，这在一段时间内看起来像是“要走的路” 为我提供 gmail API 的挂钩。我和他们一起玩了一会儿，制作了一个网络应用程序脚本来收集我所有的 gmail 邮件的主题行并将它们转储到同样由脚本构建的 UI 中，只是为了获得一个实验性的快速感觉，以了解事物如何组合在一起。该脚本有效，但似乎很慢，大约需要一分钟来收集和显示 57 个电子邮件主题行。而且我真的不知道如何将任何脚本构建的 UI 放入 gmail 用户界面。我尝试使用引用的我的应用程序脚本的 URL 构建一个侧栏小工具（内容标记正文中根本没有 HTML 或 javascript）。一个区域已分配给小工具，但我的脚本 UI 从未出现在其中。在尝试让我的脚本在完全不同的上下文中的 iframe 中运行有点失败之后，
我知道我的问题有点大，但是我“应该”寻找其他谷歌技术来构建我想到的那种东西，还是我“大致”遵循一条站得住脚的轨道。我想我正在寻找一些粗略的架构建议，一些关于我可能应该进一步探索的提示。