桌面通知功能能够让浏览器即使是最小化状态也能将消息通知给用户。这和WebIM是最为天然的结合。不过，目前支持Desktop Notification功能的浏览器只有Chrome5+。
关于通知的基础知识可以参考以下文档：
W3C标准:https://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications/
使用教程:https://www/5rocks.com/en/tutorials/notifications/quick/
本文主要记录通知功能在Web IM中实际使用时的一些经验。

在实际使用的过程中，应该尽量减少通知功能对用户的干扰，最大程度的减少通知功能的出现，这就需要解决以下几个问题：
1. 收到多条消息时确保只出现一条通知；
2. 当用户处于IM出现的页面中时(页面处于Focus状态)将不出现通知；
3. 当用户使用多Tab开启多个存在IM的页面时，只要有一个页面处于Focus状态将不出现通知；
此外，还需要解决一个便利性问题
4. 如何让用户点击通知浮动层即可定位到具体的聊天窗口

在实际上项目当中，经常需要使用短轮询(每隔一定时间就向服务器发送一次请求，请求通常会立即返回)和长轮询(每次请求服务器会Hold一段时间直到有新数据或者超时，客户端收到数据后会立即进行下一次请求）来从服务器拉取数据，然后动态的更新页面。随着功能的增加，一个页面中往往存在不止一个这样的轮询请求，而且在用户开启多个Tab页面时，总得请求数会翻倍。而“请求同步”指的是在以上场景中，即使是开启多个Tab也只有一个Tab页面维持轮询连接，一旦数据返回后，就将数据同步到其他无连接的页面，最大程度的减少请求。实现的思路也很简单，先解决由谁来进行请求的问题，之后基于本地存储将数据进行同步即可。具体的实现则有不少细节需要注意的，以下详细阐明。

本文介绍Tab之间的操作同步的实现，所谓操作同步是指将用户在某个Tab窗口中的操作同步到所有其他同一站点得Tab中。例如IM窗口的操作（打开、最大化、最小化、关闭、设置等），由于很多用户会在多个Tab之间切换，而IM在每个页面中都存在，因此对于数据同步的要求是比较高的，以前的做法是使用服务器方式来同步，即所有操作都向服务器发请求，然后广播，Tab收到消息后再响应。缺点是比较浪费资源，另外延时也比较严重。

很早之前调研过HTML5的本地存储-《DOM Storage全解析》，大致上对localStorage、sessionStorage等API做了下了解，但是一直没有机会真正的在项目中使用。终于这次借重构Web IM的机会，对本地存储做了更深入的使用，除了基本的API使用之外还在次基础上封装了一些应用层的库，例如Tab之间的操作同步、Tab之间的请求同步等。本文主要做一个阶段性的经验总结。